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
We came across an old Type 1 font with an /Encoding array populated explicitly (no /StandardEncoding, etc.), and the first entry was /NUL (for code 0). The code in Type1Input::ParseEncoding() simply adds "NUL" as the character name, and that leads to issues if code glyph 0 is actually used... Type1Input::CalculateDependenciesForCharIndex() and Type1Input::GetGlyphCharString() will probably not be able to find an entry for it in mCharStrings, leading to an error.
The text was updated successfully, but these errors were encountered:
The font in question is a .pfb file we've created on-the-fly from a Type 1 font packaged in a Mac font suitcase (i.e. it's defined in 'POST' resources in the resource fork of the file). Since the private encoding actually does provide a name for that index, the code to try to add dependent glyphs (or near there) actually tries to look up a charstring for that glyph, and not every glyph in the private encoding has a charstring. We also ran into issues with some other fonts that don't have charstrings for whatever glyph 0 [it's added on purpose in Type1ToCFFEmbeddedFontWriter::CreateCFFSubset(), even if none of the text in the document uses glyph 0], which led to failures elsewhere.
We came across an old Type 1 font with an /Encoding array populated explicitly (no /StandardEncoding, etc.), and the first entry was /NUL (for code 0). The code in Type1Input::ParseEncoding() simply adds "NUL" as the character name, and that leads to issues if code glyph 0 is actually used... Type1Input::CalculateDependenciesForCharIndex() and Type1Input::GetGlyphCharString() will probably not be able to find an entry for it in mCharStrings, leading to an error.
The text was updated successfully, but these errors were encountered: