A bug in old v.3.2.2 prevented the user from choosing ZIP compression, instead of lossy compression, for pictures in PDF/A mode. The new v.3.3.0 has fixed that bug -- hurrah! However there is still a color problem in PDFCreator's PDF/A mode.
I started with a document in Word 2013, with an hefty RGB picture in it, and printed it six ways:
- Using PDFCreator to PDF/A-1b
- Using PDFCreator to PDF/A-2b
- Using PDFCreator with High Quality profile
- Using Neevia Printer to PDF/A-1b
- Using Neevia Printer to PDF/A-2b
- Using Neevia Printer with Preprint profile.
I've uploaded all six PDFs. reddish pdfs. All six PDFs have practically equal filesize, so they must have gotten the same ZIP image compression. All the PDFs are RGB.
When comparing the appearances of the six PDFs there is a dependence on the program used for opening them. In Mac OSX, letting Preview open them, they all look the same. However, letting Adobe Reader open them, PDFs #1 and #2 look very different from the other four. In #1 and #2, in the picture, the light projections on the wall look quite reddish. This is wrong, and unacceptable. In all the others, #3-#6, they're barely reddish, which is acceptable. In Win 10, letting either Adobe Reader or Acrobat Pro open them, again PDFs 1 & 2 are quite reddish, while the other four are acceptable.
I confirmed my visual judgements with measurements on #1 and #4 opened two ways. Aiming the Mac Digital Color Meter at an 11x11 pixel patch, here are the R,G,B results:
in Adobe Reader:
#1 (PDFCreator PDF/A-1b)...172, 156, 147
#4 (Neevia PDF/A-1b):..........174, 164, 155
#1 (PDFCreator PDF/A-1b)...174, 165, 155
#4 (Neevia PDF/A-1b)...........174, 165, 155
The measurement for #1 viewed in Adobe Reader sticks out like a sore thumb. (The 165 vs 164 G discrepancy is real, but insignificant.)
So, there is something "fishy" about the PDF/A files made with PDFCreator. The Adobe software finds some data in the files that causes wrong color presentation. The Apple software ignores that data. Adobe Reader is the most popular viewer for PDFs, so even if this is a case of Adobe incompetence, we don't want to make PDF/A files that lead to wrong color presentation.
I suspect the fishy bits are in the metadata, but I haven't examined the different PDFs' binaries. PDFCreator uses iTextSharp 5.5.12 (AGPL-version) to make PDF/A. Perhaps the color problem comes from that.
Color problems aside, PDFs #1 and #2 are valid PDF/A according to the 3-HEIGHTS PDF VALIDATOR ONLINE TOOL, while PDF #5 made by Neevia fails that validation.
Bugs are everywhere. They are the spice of life for some of us. Notice how Dürer switched the Butzenscheiben alignment on the wall.