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
In a TTF font, ttfunk doesn't seem to always use the notdef glyph when a glyph cannot be found.
This is a tricky bug to reproduce because it largely depends on what other characters are present and what glyphs the font provides. For certain fonts, when certain combinations of characters are used, the notdef glyph gets replaced with what appears to be a random glyph.
Here's an example that uses a font in the prawn data folder:
In the generated PDF, we see an "L" in the position of the second to last character. If you copy that and paste it into an editor, you'll see the correct glyph. (See https://www.fileformat.info/info/unicode/char/020a/index.htm). So the problem appears to be what's being displayed from the font, not the text that's stored.
The text was updated successfully, but these errors were encountered:
In a TTF font, ttfunk doesn't seem to always use the notdef glyph when a glyph cannot be found.
This is a tricky bug to reproduce because it largely depends on what other characters are present and what glyphs the font provides. For certain fonts, when certain combinations of characters are used, the notdef glyph gets replaced with what appears to be a random glyph.
Here's an example that uses a font in the prawn data folder:
In the generated PDF, we see an "L" in the position of the second to last character. If you copy that and paste it into an editor, you'll see the correct glyph. (See https://www.fileformat.info/info/unicode/char/020a/index.htm). So the problem appears to be what's being displayed from the font, not the text that's stored.
The text was updated successfully, but these errors were encountered: