Summary: | pdfwrite : GlyphNames2Unicode | ||
---|---|---|---|
Product: | Ghostscript | Reporter: | Igor Melichev <igor.melichev> |
Component: | General | Assignee: | Igor Melichev <igor.melichev> |
Status: | NOTIFIED FIXED | ||
Severity: | normal | ||
Priority: | P1 | ||
Version: | master | ||
Hardware: | All | ||
OS: | All | ||
Customer: | Word Size: | --- |
Description
Igor Melichev
2003-02-10 11:33:21 UTC
Comment originally by igorm@users.sourceforge.net Logged In: YES user_id=79484 I'm sorry, I was some wrong. I have no CIDFontType 2 examples. I've only got Type 3 and Type 42 examples with GlyphNames2Unicode. The attached t.ps is type 3. Comment originally by igorm@users.sourceforge.net Logged In: YES user_id=79484 I desided to enhance the functionality of gs_font_procs::glyph_info instead adding a new virtual method. It must be safe for PCL interpreter. Comment originally by igorm@users.sourceforge.net Logged In: YES user_id=79484 Type 3 with GlyphNames2Unicode is used only for interpreters which cannot handle Type 32. Comment originally by igorm@users.sourceforge.net Logged In: YES user_id=79484 With Type 3/32, if the interpreter maintains Type 32 (the fragment "32 /FontType resourcestatus" returns true), GlyphNames2Unicode are not created. This is how the generated document behaves. Only way to obtain the codes is to signal the absence of Type 32 support (Idioms cannot help because 'bind' is not applied to the check). Comment originally by igorm@users.sourceforge.net Logged In: YES user_id=79484 I shall introduce a new function to gs_font_procs, because enhancing gs_font_procs::glyph_info causes multiple redundant code. It would be nice to use C++ templates... Comment originally by igorm@users.sourceforge.net Logged In: YES user_id=79484 Patches http://www.ghostscript.com/pipermail/gs-cvs/2003- February/002932.html http://www.ghostscript.com/pipermail/gs-cvs/2003- February/002934.html http://www.ghostscript.com/pipermail/gs-cvs/2003- February/002935.html |