pdf-association
Odd exception in PDF/X-6 font width requirements
32000-2:2020 9.2.4 says that the widths stored in the font dictionary "shall be consistent with the actual widths given in the font program".
15930-9:2010 6.8.4 says (my emphasis):
For every font embedded in a conforming file, the glyph width information in the font dictionary and in the embedded font program shall be consistent for every glyph referenced for rendering. Glyphs that are referenced only with rendering mode 3 are exempt from this requirement.
That exemption seems wrong on two levels:
-
It gives a confusing impression that it's contradicting a normative reference by loosening a requirement.
-
Consistency is desirable even with rendering mode 3 so that any following marks that are not in mode 3 will appear in the right place. The underlying rule is to enable some tools to read widths from the font dictionary and some from the embedded font and give equivalent results from both approaches. I don't see any reason to assume that a tool that normally reads widths from the embedded font would switch to using the font dictionary instead for rendering mode 3.
I recommend that the whole of para 1 of 6.8.4 is simply deleted as replicating a requirement from 32000-2.
So that exemption was added as an alignment with PDF/A, which pretty much exempts all Font requirements on text in render mode 3.
Your point about non-Tr 3 following immediately after Tr 3 is a good one, but the PDF/A community may wish to evaluate that as well.
I think this exception first shows up in the Corrigendum 2 to PDF/A-1. The original text of PDF/A-1 says:
For every font embedded in a conforming file, the glyph width information stored in the Widths entry of the font dictionary and in the embedded font program shall be consistent.
The Corrigendum 2 version is:
For every font embedded in a conforming file and used for rendering, the glyph width information in the font dictionary and in the embedded font program shall be consistent.
Then there were many discussions on what "used for rendering" means, and it was decided that glyphs used only in rendering mode 3 are not used for rendering. Thus they are exempt from this width consistency requirement.
But I do agree that even if they are invisible, their width might affect the placement of other glyphs.
The history of limiting this to visible text is that in reality there are many, many issues in existing PDFs especially in OCR text. This limitation was introduced to limit corrections to the really necessary, since you will for a correction have to decide which one wins, the entry in the font or the one in the PDF.
The result of removing this provision from PDF/A would mean that validation will normally not cover it anymore. We should for PDF/A decide - if we go that route - whether we want a para that says that PDF have to comply to the provision in ISO32000-2 if we want to avoid that.
Discussed at PDF/A TWG: it is reconfirmed that this exception for fonts used only in rendering mode 3 was in place in all PDF/A standards starting from PDF/A-1, Corr. 2 and is not causing any problems in practice.
@MPBailey would this be a problem for PDF/X-6?
At least in theory the problem it could cause is exactly as I stated in point 2 of the original description. If a series of glyphs are placed in render mode 3 and then followed by something else (e.g. visible text) that relies on the current point established by placing the invisible text, and if the widths in the embedded font and in the font dictionary are different then different tools will, quite legitimately, produce different visual appearances.
Since a large part of the purpose of PDF/X is to minimise variations in visual appearance, that would be A Bad Thing™.
But I will admit that I am not aware of any instances of that happening; render mode 3 is not used much in files that are generated for production printing (unlike archiving, legal and business exchange, where scanning and OCR is reasonably common, as Dietrich said above).
So I would prefer that this were 'fixed' in PDF/X if we happened to be developing errata documents for it anyway, but this is definitely not substantive enough to trigger an amendment on its own.
As I recently said under issue 77, the goal should be to ensure that it is possible to create a file that conformed to both PDF/X and PDF/A, without constraining it beyond what is necessary to conform to each individually. That doesn't imply a need for adding all of the PDF/A constraints to the PDF/X standard or vice versa.
Aligning X/A TWG does not see a need to address this in the upcoming DR's, but will leave the issue parked should a good reason for doing so come up in the future.