Is there no picture control with PDF/A?


#1

I made three profiles. They all make
Output Format: PDF/A-1b,
Page Orientation: Auto-Detect,
Color Model: RGB
Profile 1 makes Image compression: ZIP
Profile 2 makes Image compression: JPEG (Maximum)
Profile 3 makes Image compression: JPEG (Minimum)

I have an MS Word document with many PNG illustrations. The document file is 13.4 MB. I printed the document using each of the three profiles.
Profile 1 makes a PDF/A file with size 4958435 bytes.
Profile 2 makes a PDF/A file with size 4958435 bytes
Profile 3 makes a PDF/A file with size 4958435 bytes
The files are likely identical, the Image compression descriptor in the profile doing nothing. Moreover, the PDF/A is made with much image compression. Is there no way to make a PDF/A that preserves the original document's image qualities when using PDF Creator? A functioning Profile 1 is desired.

From the same Word document competing software from Neevia made a PDF/A file with size 12888347 bytes, more in line with the original document's size. The images in that PDF/A are visibly better -- same resolution but less compression artifacting -- than those in the ones from PDF Creator.

Maybe the error is mine. Where does PDF Creator store its profiles in order to check them?


#2

Hi,

sorry for the trouble, you are right, this is currently broken (compression is ignored when creating PDF/A) but will be fixed in the next PDFCreator and PDFCreator Server releases, the bug has already been found and corrected.

Best regards

Robin


#3

Oddly, Neevia also ignored compression when creating PDF/A. But it defaulted to something like ZIP, which is what I needed when I paid them 19 USD.
Sometimes more compression is desired for archiving, sometimes not.
It will be good when PDFCreator offers the choices.


#4

The update including the fix should get released for PDFCreator Server in early September, the desktop version will take longer though. I am not sure which is the last version of PDFCreator where this is still working, but it might be worth trying with 2.5.3 as there was a big redesign afterwards: http://download.pdfforge.org/download/pdfcreator/2.5.3/PDFCreator-2_5_3-Setup.exe?file=PDFCreator-2_5_3-Setup.exe


#5

Thank you for this information. I share your curiosity. Unfortunately v.2.5.3 wouldn't install on my Win 10 system. Error messages: "PrinterHelper stopped working" "PDFCreator was not able to repair your printers". I found an old v.2.4.0 installer. Unfortunately it too didn't work.

After those attempts I couldn't reinstall v.3.2.2. A "No printers installed" message, and again "PDFCreator was not able to repair your printers." Luckily I'd cloned the system just before and am now back where we started.

Curiosity shifts to how v.3.2.2 will be repaired. With v.3.2.2, PDF/A images, besides being recompressed, have quite off colors. Two separate problems, though perhaps from one cause.


#6

Have you checked if there is any conversion from RGB to CMYK (which could slightly change colors)?
The fix only ensures the selected compression will actually get applied.
With zip compression and no conversion from RGB to CMYK there shouldn't be any difference in the input and output images.

Best regards

Robin


#7

In v.3.2.2, with the "PDF/A" profiles the "Image compression" setting is broken; it does nothing. But the "Color Model" setting does something. Setting it to "CMYK" instead of "RGB" makes the colors look different. It also makes a file 3.2× larger. That's crazy when CMYK only uses 1.33× as many bits per pixel as RGB does. v.3.2.2 is depending on iTextSharp 5.5.12 for its PDF/A printing. Is that safe?

I think the previously mentioned PDF/A-1b with unwanted image compression and poor color is RGB. It is a photo of the "shadows" on the cove wall in Dürer's famous "Hieronymus im Gehäus" engraving. His black hatching is so fine there that you might think he used grey ink. I suspect that the heavy image compression of the fine black and white structure is what distorted the apparent tone to awful pink. (It could exaggerate a slight pink already there.) So it is not a color encoding error per se.