| Summary: | gs 8.63. Option dPDFA generating no pdf/a compliant files because of F key. | ||
|---|---|---|---|
| Product: | Ghostscript | Reporter: | J. Arteaga <jose.arteaga> |
| Component: | PDF Writer | Assignee: | Ken Sharp <ken.sharp> |
| Status: | RESOLVED FIXED | ||
| Severity: | critical | ||
| Priority: | P4 | ||
| Version: | 8.63 | ||
| Hardware: | Other | ||
| OS: | Linux | ||
| Customer: | Word Size: | --- | |
| Attachments: |
test.pdf
converted_test.pdf adobe_acrobat_screenshot.png |
||
Created attachment 5044 [details]
test.pdf
This a 13 page file, not pdf/a compliant by breaking some of the rules (not
embedded fonts, no valid metadata, etc...)
Created attachment 5047 [details]
converted_test.pdf
And this is the output file from the specified command. PDF/A-1b compliant
except for the "The key <<F>> is required...".
It happens with every pdf file I try.
The original file contains (on page 13) two Link annotations, one for each of the ibm.com URLs. These annotations do not have a /F key which means the default is used, the default is 0. This means the 'Print' flag is not set, PDF/A compliance requires that a /F key be present, that the Print flag be set and that certain other flags *not* be set. So the original file should fail PDF/A validation, and indeed does so when I preflight it with Acrobat. It *should* fail for the 'key F is required' reason and does with Acrobat (amongst other reasons), this seems to be a problem with the Solid Documents tool. Its not at all clear what we should do about this. We definitely do *NOT* want to set the annotation flags to 'print' as this would overprint on top of the existing text in the document. Also this is a Link annotation, and while the text matches in this case (URL) it need not do so at all. Thus there are two possibilities: 1) Abort PDF/A compliance and emit a warning to that effect (possibly abort file creation altogether). 2) Drop the annotation altogether if it does not have appropriate settings for PDF/A emission. I believe there are other areas where these sorts of decisions need to be taken, so I propose we add a 'Policy' of some kind to determine what we should do under these conditions. I'll consider how to implement this later. As a matter of fact, it fails for "the key F is required" when validated; it was my mistake saying no. But, the converted file still fails for key F. I tested with 8.64 and it's the same thing. Created attachment 5054 [details] adobe_acrobat_screenshot.png Regarding comment #3: Adobe Acrobat 9 Pro emits an error message when trying to convert the file to PDF/A-1a (see attached). Ken, regarding comment #3: I think choice 1 is the correct default. That's what Acrobat does. Fixed in revision 9876, patch here: http://ghostscript.com/pipermail/gs-cvs/2009-July/009574.html The new switch PDFCompatibilityPolicy controls how the file is created when this condition is encoutnered. See (the modified) ps2pdf.htm for more details. |
1. I test the file "test.pdf" against a pdf/a validator. Some errors arise (test.pdf is not pdf/a compliant), but "The key F is required" is'nt among them. 2. I run: gs -q -sDEVICE=pdfwrite -dNOPAUSE -dBATCH -dNOSAFER -dPDFA -dUseCIEColor -sProcessColorModel=DeviceCMYK -sOutputFile=converted_test.pdf PDFA_def.ps test.pdf 3. I test "converted_test.pdf" against the pdf/a validator. No errors now but this one: "The key <<F>> is required for PDF/A-1b" Every pdf file the command converts is marked with the same error in a validator tool. This is the complete message from the validator (BTW it's validatepdfa.com from "Solid Documents" -sic) <annotations> <problem severity="error" objectID="117" clause="6.5.3" standard="pdfa" page="13">The key <<F>> is required for PDF/A-1b</problem> <problem severity="severeError" clause="6.5.3" standard="pdfa" page="13">Flag '4' is required for the key <<F>></problem> I tested also the validator with Isartor testsuite, and it's doing ok; so I know validator's working right.