Summary: | ps2pdf problem with CFF fontset resources | ||
---|---|---|---|
Product: | Ghostscript | Reporter: | Werner Lemberg <wl> |
Component: | PDF Writer | Assignee: | leonardo <leonardo> |
Status: | NOTIFIED FIXED | ||
Severity: | normal | CC: | hanwen, htl10 |
Priority: | P3 | ||
Version: | 8.50 | ||
Hardware: | PC | ||
OS: | Linux | ||
URL: | http://groff.ffii.org/groff/gs-bug/minimum.ps | ||
Customer: | Word Size: | --- | |
Attachments: |
encoding-embed-bug.ps
minimum.ps |
Description
Werner Lemberg
2005-04-02 21:45:37 UTC
Could it be that this problem is not limited to the PDF writer? My printer barfs on relatively simple music pages (ESP GS 8.15, pxlmono, 1200dpi for LJ2100M with 16mb) that contain a binary CFF font, but the same page prints gracefully if I substitute a PFA file of the same font. I seem to get the same behavior with CVS HEAD. Assigning to Igor. Created attachment 1292 [details]
encoding-embed-bug.ps
This file provides a single entry in the Encoding vector, then accesses
two glyphs with glyphshow, one of them is in the Encoding, the other
isn't.
The new attachment encoding-embed-bug.ps probably exhibits the problem more clearly. Two glyphs of the same font (one with encoding entry, one without) are accessed, and ps2pdf embeds the glyph with an Encoding entry, and expands the other one. Note that this problem doesn't happen for standard fonts like Helvetica. Created attachment 1341 [details]
minimum.ps
Saving a copy of the test file.
It requires an improvement to pdf_make_text_glyphs_table_unencoded and its surrounding. The improvement needs to mix glyph codes for standard and instandard glyph names (see big comment in gsccode.h about Codes < gs_c_min_std_encoding_glyph and Codes >= gs_c_min_std_encoding_glyph). The consumers must carefully distinguish them. The latter isn't a small or a local fix, so it can't be done quickly. Reducing the priority because it's not a customer bug. Thanks for the analysis. Is there any easy workaround? Basically, we would like to include our font (with custom glyphs) into the PS file so that the ps2pdf engine does proper subsetting. We can change the font format easily if necessary. As a workaround, try to provide entries for all used glyphs in the font's Encoding. *** Bug 688123 has been marked as a duplicate of this bug. *** Patch to HEAD : http://ghostscript.com/pipermail/gs-cvs/2006-February/006323.html The change unexpectedly occured pretty simple. Likely Comment #6 is very obsolete. Very cool! thanks for your work! I assume that I'm allowed to backport such a small fix to the ESP/GPL versions of GhostScript? (would that work?) Dear Han-Wen Nienhuys, You may try to port it, but I'm not sure that it will be compatible with implementation of other functions in the GPL Ghostscript. So try and see what happens, if you succeed, please attach the patch to here. Hi, it seems to work with 8.50-gpl with the patch that you link. It applies without rejects, and it seems to work. ESP Ghostscript 8.15.1 is also fine. |