Type1Input::ParseEncoding() in Type1Input.cpp interprets /NUL as a character name rather than ".notdef"

[TheGS]

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.

[galkahana]

what do you suggest to do?

[galkahana]

I'd love to see a code sample where this actually fails. it seems to me that since /NUL is recorded as the glyph name for 0 (https://github.com/galkahana/PDF-Writer/blob/master/PDFWriter/Type1Input.cpp#L424) and that encoding is per index (https://github.com/galkahana/PDF-Writer/blob/master/PDFWriter/Type1Input.cpp#L751) that we shouldn't really have a problem.

can you hook up something? [i'll need the sample font too].

Gal.

[TheGS]

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.