Bugzilla – Bug 688017
ps2pdf problem with CFF fontset resources
Last modified: 2008-12-19 08:31:56 PST
If I embed a CFF fontset resource in a PS document like this:
%%+ font foo
%%BeginResource: font foo
%%DocumentNeededResources: ProcSet (FontSetInit)
%%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?
gives an example: After embedding, there isn't a font called Emmentaler-20
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]
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
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]
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
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
*** Bug 688123 has been marked as a duplicate of this bug. ***
Patch to HEAD :
The change unexpectedly occured pretty simple.
Likely Comment #6 is very obsolete.
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.
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.