I encountered a situation where VeraPDF reports a PDF/A error for a TrueType font that is not embedded and used exclusively with Text Rendering Mode 3 (invisible text). According to the PDF/A-1 specification (ISO 19005-1:2005), this configuration should be exempt from visual requirements, including embedding and Differences array constraints. In Adobe Preflight i dont see this reported as an error.
Scenario
- Font type: non-symbolic TrueType
- Encoding: WinAnsiEncoding with Differences array
- Differences mapping: e.g., code 4 mapped to /S (included in the Adobe Glyph List)
- Font embedding: not embedded
- Text rendering mode: exclusively 3 (invisible text) on a scanned pdf
verapdf fails with clause 6.2.11.6 mentioned:
All non-symbolic TrueType fonts shall have either MacRomanEncoding or WinAnsiEncoding as the value for the Encoding key in the Font dictionary or as the value for the BaseEncoding key in the dictionary that is the value of the Encoding key in the Font dictionary. In addition, all non-symbolic TrueType fonts shall not define a Differences array unless all of the glyph names in the Differences array are listed in the Adobe Glyph List and the embedded font program contains at least the Microsoft Unicode (3,1 Platform ID = 3, Encoding ID = 1) encoding in the 'cmap' table
I observe, that when i embed this font, it is valid according to verapdf.
In 6.2.11.1 General we have this exception in the spec.
The intent of the requirements in 6.2.11.2 to 6.2.11.8 is to ensure that the future rendering of the textual
content of a conforming file matches, on a glyph by glyph basis, the static appearance of the file as
originally created and, when possible, to allow the recovery of semantic properties for each character
of the textual content. Unless a requirement specifically states that it shall only apply to text that would
be rendered by a conforming reader, they shall apply to any font including those used exclusively with
text rendering mode 3.
So in my understanding the requirement of the embedded cmap Microsoft Unicode (3,1 Platform ID = 3, Encoding ID = 1) falls unter above exception, because it is only needed for rendering. The Glyph mapping is completly done by WinAnsi Encoding / Adoby Glyph List mapping.
Am i wrong here?
Used verapdf version: 1.28.2
verapdftest.pdf
I encountered a situation where VeraPDF reports a PDF/A error for a TrueType font that is not embedded and used exclusively with Text Rendering Mode 3 (invisible text). According to the PDF/A-1 specification (ISO 19005-1:2005), this configuration should be exempt from visual requirements, including embedding and Differences array constraints. In Adobe Preflight i dont see this reported as an error.
Scenario
verapdf fails with clause 6.2.11.6 mentioned:
All non-symbolic TrueType fonts shall have either MacRomanEncoding or WinAnsiEncoding as the value for the Encoding key in the Font dictionary or as the value for the BaseEncoding key in the dictionary that is the value of the Encoding key in the Font dictionary. In addition, all non-symbolic TrueType fonts shall not define a Differences array unless all of the glyph names in the Differences array are listed in the Adobe Glyph List and the embedded font program contains at least the Microsoft Unicode (3,1 Platform ID = 3, Encoding ID = 1) encoding in the 'cmap' table
I observe, that when i embed this font, it is valid according to verapdf.
In 6.2.11.1 General we have this exception in the spec.
The intent of the requirements in 6.2.11.2 to 6.2.11.8 is to ensure that the future rendering of the textual
content of a conforming file matches, on a glyph by glyph basis, the static appearance of the file as
originally created and, when possible, to allow the recovery of semantic properties for each character
of the textual content. Unless a requirement specifically states that it shall only apply to text that would
be rendered by a conforming reader, they shall apply to any font including those used exclusively with
text rendering mode 3.
So in my understanding the requirement of the embedded cmap Microsoft Unicode (3,1 Platform ID = 3, Encoding ID = 1) falls unter above exception, because it is only needed for rendering. The Glyph mapping is completly done by WinAnsi Encoding / Adoby Glyph List mapping.
Am i wrong here?
Used verapdf version: 1.28.2
verapdftest.pdf