Created attachment 26709 [details] PDF that doesnt conform to PDF/A-3b after running through GS I am creating a simple tool for converting PDFs to PDF/A-3b and testing them on various PDFs and then testing those on VeraPDF. I found one PDF, that doesn't seem to conform after conversion with ghostscript. I am attaching the file. After doing the steps described here https://ghostscript.readthedocs.io/en/latest/VectorDevices.html#creating-a-pdf-a-document the resulting file still shows error in verapdf > Specification: ISO 19005-3:2012, Clause: 6.2.11.8, Test number: 1 > > A PDF/A-3 compliant document shall not contain a reference to the .notdef glyph from any of the text showing operators, regardless of text rendering mode, in any content stream
(In reply to Karel Bilek from comment #0) > Created attachment 26709 [details] > PDF that doesnt conform to PDF/A-3b after running through GS This is the file produced as output by the pdfwrite device. This is not helpful. We need: 1) The original input file 2) The command line used 3) Any other files required to create the output (in this case the ICC prfile and the modified pdfa_def.ps file at the very least).
Created attachment 26726 [details] VeraPDF test suite fail
Created attachment 26727 [details] Output
Created attachment 26728 [details] default rgb ICC
Created attachment 26729 [details] PDFA def ps
I found out that VeraPDF has test suite with atomic tests for each PDF/A validation error, which will be much better than my random file. So, now this file; I am also attaching it for posterity https://github.com/veraPDF/veraPDF-corpus/blob/staging/PDF_A-2b/6.2%20Graphics/6.2.11%20Fonts/6.2.11.8%20Use%20of%20.notdef%20glyph/veraPDF%20test%20suite%206-2-11-8-t01-fail-a.pdf raw link: https://raw.githubusercontent.com/veraPDF/veraPDF-corpus/eb5344d4712aed8ada477828101005d63d141fbb/PDF_A-2b/6.2%20Graphics/6.2.11%20Fonts/6.2.11.8%20Use%20of%20.notdef%20glyph/veraPDF%20test%20suite%206-2-11-8-t01-fail-a.pdf The command line used: ``` gs -dNOSAFER -dPDFACompatibilityPolicy=2 -dPDFA=3 -dBATCH -dNOPAUSE -sColorConversionStrategy=RGB -sDEVICE=pdfwrite -sOutputFile=out.pdf /tmp/pdfa_def.ps ./veraPDF\ test\ suite\ 6-2-11-8-t01-fail-a.pdf ``` The output is attached. Also gs version: `` gs -version GPL Ghostscript 10.05.0 (2025-03-12) Copyright (C) 2025 Artifex Software, Inc. All rights reserved. ```
(In reply to Karel Bilek from comment #6) > I found out that VeraPDF has test suite with atomic tests for each PDF/A > validation error, which will be much better than my random file. > > So, now this file; I am also attaching it for posterity Never mind posterity, you must attach files here, not post URLs. We require the file for future reference and URLs can go stale, so we insist files be attached to bug reports so we always have a record. So... You are taking a known failing file and expecting GhostScript to turn it into a working file. For the test case in question that isn't going to happen. The original file uses the /.notdef glyph, which is not permitted in PDF/A (and is an outstandingly silly thing to do for any file). We cannot alter the /.notdef glyph because all fonts require one. We can't determine if the /.notdef glyph is used because of an error or because the input was silly enough to use it as a marking glyph. So we can't rewrite the character with a different name. We *might* be able to spot the use of a /.notdef and issue a warning. I'm too busy to look into that right now, but its the only likely possibility.
Thanks for the explanation.
Would rendering the .notdef glyph as lines/bitmaps, as -dNoOutputFonts does, specifically just in the case of PDF/A conversion, work too?
(In reply to Karel Bilek from comment #9) > Would rendering the .notdef glyph as lines/bitmaps, as -dNoOutputFonts does, > specifically just in the case of PDF/A conversion, work too? Rendering to a bitmap instead of a character would work, but obviously at the expense of losing fonts and scalability.
Enhancement committed 67f8e94cf79c39b79c53300f2462ca3f2c65bec1
Thanks for the commit!