You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The PDF-2.0 specification is ambiguous about which glyph width should be used for text layout when a missing character is replaced through the notdef mapping mechanism in composite fonts. It would be nice if this could be clarified, either in section 9.7.6.3 or in section 9.4.4.
Details
Section 9.7.6.3 (Handling undefined characters) explains the use of notdef mappings for composite fonts: If a code maps to a CID which is not present in the font, normally CID 0 is shown instead. A "notdef mapping" allows to specify an alternative CID for a glyph to show in place of the missing one. The spec does not specify which of these CIDs (the one corresponding to the missing glyph, or the replacement) defines the "glyph width" used for text layout. (Note that glyph widths are specified by CID, so are available even for missing glyphs.)
In case where the CID given in the notdef mapping also maps to a missing glyph, CID 0 is used instead. In this case, there are three different candidates for which width should be used: the original CID, the CID from the notdef mapping, or CID 0. Again, the spec does not specify which CID should be used.
Section 9.4.4 (Text space details) describes the parameters $w0$ and $w1$ as "the glyph's horizontal and vertical displacements" (emphasis mine). However, when a missing glyph is replaced, the spec is not clear whether "the glyph" refers to the missing glyph or the replacement.
Test File
The attached pdf file can be used to determine the behaviour of different PDF viewers. Each test case shows text with different combinations of missing glyphs and notdef mappings. The file is more or less human readable. The CMap with the notdef mappings is near the start of the file, the content stream is further down in object 8.
The tests use a font embedded in the PDF file. I have not attempted to test whether behaviour for external fonts is different.
Viewer Behaviour
Just focussing on the glyph width, I found the following results. All tests were performed on MacOS. (Test numbers in the list below refer to the "test.pdf" file.) I have tried Adobe Reader, Ghostscript, Google Chrome, Firefox and Mac Preview.
Test 3: Code mapped to a missing glyph: All viewers use the width of the missing glyph.
Test 4: unmapped code; custom notdef glyph: Adobe Reader, Ghostscript and Mac Preview use the width of the notdef glyph; Google Chrome and Firefox use the width of CID 0.
Test 5: Code mapped to a missing glyph; custom notdef glyph: All viewers use the width of the missing glyph.
Test 6: unmapped code; missing, custom notdef glyph: Adobe Reader, Ghostscript and Mac Preview use the width of the missing notdef glyph; Google Chrome and Firefox use the width of CID 0.
Test 7: Code mapped to a missing glyph; missing, custom notdef glyph: All viewers use the width of the missing glyph.
As an aside: While the choice of glyphs shown differed between viewers, none of the viewers I tried actually showed the custom notdef glyphs when a code maps to a CID where the glyph is missing.
The text was updated successfully, but these errors were encountered:
The PDF-2.0 specification is ambiguous about which glyph width should be used for text layout when a missing character is replaced through the notdef mapping mechanism in composite fonts. It would be nice if this could be clarified, either in section 9.7.6.3 or in section 9.4.4.
Details
Section 9.7.6.3 (Handling undefined characters) explains the use of notdef mappings for composite fonts: If a code maps to a CID which is not present in the font, normally CID 0 is shown instead. A "notdef mapping" allows to specify an alternative CID for a glyph to show in place of the missing one. The spec does not specify which of these CIDs (the one corresponding to the missing glyph, or the replacement) defines the "glyph width" used for text layout. (Note that glyph widths are specified by CID, so are available even for missing glyphs.)
In case where the CID given in the notdef mapping also maps to a missing glyph, CID 0 is used instead. In this case, there are three different candidates for which width should be used: the original CID, the CID from the notdef mapping, or CID 0. Again, the spec does not specify which CID should be used.
Section 9.4.4 (Text space details) describes the parameters$w0$ and $w1$ as "the glyph's horizontal and vertical displacements" (emphasis mine). However, when a missing glyph is replaced, the spec is not clear whether "the glyph" refers to the missing glyph or the replacement.
Test File
The attached pdf file can be used to determine the behaviour of different PDF viewers. Each test case shows text with different combinations of missing glyphs and notdef mappings. The file is more or less human readable. The CMap with the notdef mappings is near the start of the file, the content stream is further down in object 8.
test.pdf
The tests use a font embedded in the PDF file. I have not attempted to test whether behaviour for external fonts is different.
Viewer Behaviour
Just focussing on the glyph width, I found the following results. All tests were performed on MacOS. (Test numbers in the list below refer to the "test.pdf" file.) I have tried Adobe Reader, Ghostscript, Google Chrome, Firefox and Mac Preview.
As an aside: While the choice of glyphs shown differed between viewers, none of the viewers I tried actually showed the custom notdef glyphs when a code maps to a CID where the glyph is missing.
The text was updated successfully, but these errors were encountered: