If I embed a CFF fontset resource in a PS document like this: %%DocumentSuppliedResource: %%+ font foo ... %%BeginResource: font foo %!PS-Adobe-3.0 Resource-FontSet %%DocumentNeededResources: ProcSet (FontSetInit) %%Title: (FontSet/Emmentaler-16) %%Version: 0 %%EndComments %%IncludeResource: ProcSet (FontSetInit) %%BeginResource: FontSet (Emmentaler-16) /FontSetInit /ProcSet findresource begin %%BeginData: 63639 Binary Bytes ... ghostscript displays this PS document just fine, but it doesn't recognize this as a font while using ps2pdf. Instead, it expands each glyph usage from this font directly into outlines, which both blows up the size of the PDF document and reduces its quality because all font hints are lost. Is this a known limitation, or am I doing something wrong? The file http://groff.ffii.org/groff/gs-bug/minimum.ps gives an example: After embedding, there isn't a font called Emmentaler-20 any more.
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.