Type1Input::ParseEncoding() in Type1Input.cpp interprets /NUL as a character name rather than ".notdef" about pdf-writer HOT 3 OPEN

what do you suggest to do?

from pdf-writer.

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.

from pdf-writer.

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.

from pdf-writer.