| T O P I C R E V I E W |
| jrpcguru |
Posted - Aug 30 2024 : 15:46:21
Early in my use of ImageEn, I wrote a scanning program that was designed specifically to deal with genealogy documents and photos. This required use of metadata to store Title, Location, Source, Date, and a 2,000 character description. Initially I only was able to scan .JPG and .TIF
In due course, the WPViewPDF plug-in became available. Now I was able to save PDF files using native ImageEn and read them using WPViewPDF. Native ImageEn saved each page as an image and saved the metadata and WPViewPDF read the image. Since each page was image based, I could use common ImageEn editing such as hi-liting, redacting, layers, deskewing, stitching etc. I saved the scanning DPI into metadata, so I could set params.dpi to the correct value before loading a file. I was able to read metadata via native ImageEn, but some styles of metadata in my sample PDFs were not readable.
This worked well until I started discovering PDF files that could not be read by WPViewPDF and the publisher of that plug-in was unresponsive for well over a year. When PDFium arrived, I found that it was really fast at reading the metadata and successfully read metadata from every sample PDF that I couldn't read before and read every file that WPViewPDF couldn't read. I began using PDFium via PDFViewer.enabled = true, to read the metadata, then WPViewPDF to read each page image.
When ImageEn 13.2.0 arrived on 8 May 2024 I recompiled my program and didn't immediately notice that it no longer saved PDF files with JPG compression and didn't save metadata. The change data on your website gave no idea of the importance of the new PDF Engine property. (Suggestion: Please correct that oversight. I had no idea that this update would break important features because the change data didn't warn me.)
The default value of the PDFEngine is this, apparently:
IEGlobalSettings().PDFEngine := ieenDLL;
So the JPG compression and metadata saving disappeared.
It turns out that I was required to use:
IEGlobalSettings().PDFEngine := ieenNative;
before saving the PDF file using native ImageEn. This saved the PDF and the metadata. I was still using WPViewPDF for reading the PDF.
After ImageEn 13.5.0 arrived, I began to think about replacing WPViewPDF with PDFium to load the PDF file because when PDFium was used via PDFViewer.enabled=true, it was fast and successful at reading every type of metadata and PDF file that I have as samples.
Now, to load a file, this was required:
IEGlobalSettings().PDFEngine := ieenDLL;
And saving the PDF file:
IEGlobalSettings().PDFEngine := ieenNative;
But it turns out there was way more needed for this transition. I gave up trying to adjust my program until I was sure it was possible to make this transition. I copied your demo: C:\ProgramData\ImageEn\Demos\PDF\PDFViewer 2 and modified it to use the PDFEngine values listed above. (I would be happy to provide this revised demo, since I think your users will benefit.)
The help file was a bit unclear about PDFViewerDefaults.DPI, so for awhile I thought it applied only to PDFViewer. It actually applies to PDFEngine := ieenDLL also, when reading a PDF file.
The demo program offers 72, 144 and 288 dpi. The higher values prove to load a PDF file with much better resolution. But 288 dpi can cause some large image pages of PDFs to fail to load, but it is nice for text based PDFs.
Question: I'm not entirely clear how ImageEnView1.IO.Params.Dpi should be used. For now I'm setting it with the scanning DPI before saving. And I'm setting it before reading the PDF file and setting each page of the ImageEnMView1 before saving. I assume that it will be appropriate to set this value to the scanning DPI when saving and set both Params.dpi and PDFViewerDefaults.dpi to the same DPI value when reloading a scanned image? But it proves impossible to set ImageEnMView1.MIO.Params[0].Dpi with an empty ImageEnMView1, so I don't know if setting the ImageEnView1.params.dpi is accomplishing anything when I'm loading a PDF file.
Question: I really got myself in trouble when I started editing PDF files with the new demo and rotated some pages. Is there any way to get it to save a landscape page with its proper dimensions instead of occupying part of a portrait mode page? PDF_PaperLayout := ielLandscape doesn't seem to do anything.
Question: Is this the correct way to translate the dimensions of the ImageEnMView1 into .PDF_PaperHeight?
iDPI := ImageEnView1.IO.Params.Dpi; //as loaded or as scanned
dbSize := IEConvertToUnits(ImageEnMView1.MIO.Params[i].Height,ieuPixels,ieuInches, ImageEnView1.IO.Params.Dpi);
ImageEnMView1.MIO.Params[i].PDF_PaperHeight:= Round(dbSize * iDPI);
Suggestion: I would like to suggest that your help file include a separate topic devoted to how to transition from WPViewPDF to using PDFium. The information is scattered all around the help file and not particularly easy to marshal into a useful form. And a demo program would be a good idea, too.
J.R. |
| 3 L A T E S T R E P L I E S (Newest First) |
| xequte |
Posted - Aug 30 2024 : 20:08:58
Hi JR
Please take a look at the values of page sizes at:
https://www.imageen.com/help/TIOParams.PDF_PaperHeight.html
So if the DPI is PDF default (72) then an image of size 595 x842 px would be A4.
Nigel
Xequte Software
www.imageen.com
|
| jrpcguru |
Posted - Aug 30 2024 : 17:32:09
Thank you for the very quick response.
I look forward to your PDFium work continuing to bear fruit.
Could you address my question about how to calculate the page dimensions?
J.R. |
| xequte |
Posted - Aug 30 2024 : 17:12:09
Hi JR
Unfortunately, at this time there is no perfect solution for PDF I/O on Delphi. While ImageEn has made huge strides over the last three years (ImageEn now has the most complete Delphi implementation of PDFium without exception), there are still limitations.
Due to these limitations (and for historical reasons) we support PDF in four ways:
- PDFium: Wide format and feature support, but some notable feature limitations (e.g. saving meta data, compression, etc)
- ImageEn Native: Good feature support (save-only)
- WPPDF: Generally good, but a few quirks (read-only)
- ImageMagick+GhostScript: Generally good (read-only)
Moving forward, I expect PDFium to become more and more of our PDF focus, especially if they can plug the gaps in the API). Editing of object and annotations in ImageEn via PDFium has improved markedly in recent versions.
For documentation of PDF in ImageEn:
https://www.imageen.com/help/File_Formats.html#PDF
https://www.imageen.com/help/Keywords.html#PDF
With regard to your questions:
The default value of PDFEngine is actually ieenAuto, which (for consistency with our other engines) means that if the PDFium DLL is available, it defaults to ieenDLL, otherwise ieenNative:
https://www.imageen.com/help/TIEGlobalSettings.PDFEngine.html
The default value of Params.DPI values can be set by:
https://www.imageen.com/help/TIEGlobalSettings.DefaultDpiX.html
https://www.imageen.com/help/TIEGlobalSettings.DefaultDpiY.html
Params.DPI is set when loading PDFium files to PDFViewerDefaults.DPI. It is used as the DPI when saving PDF documents.
PDFViewerDefaults.DPI controls the size of the display of PDF documents, so if you set 144 they will display at twice the design size (72 DPI is the PDF default).
It is also used to specify the size of objects when importing PDF documents as layers, and the size when printing.
I will improve the documentation.
Nigel
Xequte Software
www.imageen.com
|
|
|
Search
