Bug 692094 - Ghostscript output not PDF/A compliant
Summary: Ghostscript output not PDF/A compliant
Status: NOTIFIED WONTFIX
Alias: None
Product: Ghostscript
Classification: Unclassified
Component: PDF Writer (show other bugs)
Version: master
Hardware: PC All
: P2 normal
Assignee: Ken Sharp
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-03-24 07:12 UTC by Marcos H. Woehrmann
Modified: 2011-10-02 02:34 UTC (History)
0 users

See Also:
Customer: 670
Word Size: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Marcos H. Woehrmann 2011-03-24 07:12:00 UTC
I won't have a chance to try and duplicate the problem until later today (CET) but here is the customer's email:

I have been testing pdf->pdf/a conversion using GS 8.71. I have installed GS 9.01 The attached source file converts to pdf/a with 8.71 but gets distiller error with gs 9.01.
 
 
Attached is a zip with
-          embeddedJpgNormal.pdf : the source file

-          out.pdf : the output file which does not verify in adobe preflight 10

-          commandlineused.txt : command line I used and description of issue

-          AdobePreflightVerificationFailReport.pdf  : failure report from adobe preflight generated when trying to verify pdfa
Comment 2 Ken Sharp 2011-03-24 08:16:17 UTC
The problem is that the original PDF file contains an embedded subset TrueType font. PDF/A requires that fonts be embedded and *not* subset.

Since we don't have the original font, we cannot embed the entire font and must embed the subset. This leads to the PDF/A non-conformance error. In fact there are no glyphs used which are not in the font, but the Acrobat pre-flight doesn't detect that, it simply notices that the font is marked as a subset and flags the error. Removing the 'XXXXXX+' prefix from the font clears the error :-)

So why did the 8.71 output not get an error ? That is due to a limitation of the pre-flight checker. The current code embeds the font as a TrueType, just like the original file, the 8.71 code embeds it as a CIDFont with TrueType outlines. It seems the pre-flight doesn't check CIDFonts.

So the file has the same problems it always has had, its simply that recent changes have exposed the problem to the pre-flight tool.

At some point I will rewrite the TrueType embedding so that we get rid of the CMAP error, but there's no getting away from the fact that if you start from a subset font, the result is always going to be a subset font, and unacceptable in a PDF/A file.