Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

glyph width when notdef mappings are present #512

Open
seehuhn opened this issue Jan 17, 2025 · 0 comments
Open

glyph width when notdef mappings are present #512

seehuhn opened this issue Jan 17, 2025 · 0 comments
Labels
bug Something isn't correct

Comments

@seehuhn
Copy link

seehuhn commented Jan 17, 2025

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.

  • 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.

@seehuhn seehuhn added the bug Something isn't correct label Jan 17, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't correct
Projects
None yet
Development

No branches or pull requests

1 participant