Type1ToCFFEmbeddedFontWriter::AddComponentGlyphs() uses the private encoding for dependent glyphs even for glyphs defined using the 'seac' operator about pdf-writer HOT 6 CLOSED

Good. How about you add your solution to hummus?

from pdf-writer.

I'd like to, especially since this particular modification itself is trivial to do, but I'm limited in how directly I can contribute at this time. I'm working on changing that, though

from pdf-writer.

@TheGS just to clarify this. basically if something coming from seac then Type1Input::GetGlyphCharStringName() should be forced to go to the else part? i could add a "force" there in that case. would that make sense?

On another matter. mind looking if my latest commit is not complete idiocy - adding support for symbol encoding, hoping i don't hurt anything...seems like i don't, but i wanted an expert opinion. here - fa35726

from pdf-writer.

It looks like the only code that ever sets CharString1Dependencies::mCharCodes is Type1Input::Type1Seac() and the only code that ever consumes CharString1Dependencies::mCharCodes is Type1ToCFFEmbeddedFontWriter::AddComponentGlyphs(), so it should be safe to just get the encoded glyph name from StandardEncoding inside the AddComponentGlyphs() implementation.. in the case of 'seac', the encoding of the font never needs to be consulted, since 'seac' requires its component character glyph codes to be in Adobe Standard Encoding by definition. That's what we ended up doing.

from pdf-writer.

Makes sense. Thanks

from pdf-writer.

k. should be taken care of with cc3b48f

from pdf-writer.