[gs-devel] Proposed new gs_font procedures
L. Peter Deutsch
ghost at aladdin.com
Sat May 25 15:41:13 PDT 2002
Thanks very much for your comments.
> This would be a great improvment for fonts with large glyph sets
> such as CJK fonts.
Please note that pdfwrite already handles CID-keyed fonts properly, emitting
subset fonts containing only the glyphs actually used. The copy_font and
copy_glyph procedures are needed primarily to handle some long-standing
problems with Type 1 and TrueType fonts, although I expect they will also
simplify the code for other font types.
> I am still new to Postscript but using the glyph IDs seems like the right
> thing as this will allow for contextual glyph substitution. Which 'show'
> variant(s) do you expect will be used to draw?
I expect COPY_FONT_ENCODING will always be used for Type 1 and TrueType
fonts, which have a meaningful concept of Encoding, and will never be used
for CIDFonts, which don't.
>> If *pfont_new already has a definition for glyph_new,
>> return gs_error_rangecheck.
> I'm curious why return and error, 'gs_error_rangecheck'. Is this intended
> to indicate an overwrite?
Yes. In general, a rangecheck error is a catch-all indicating that some
operand value was invalid. But in light of your comment, I think
gs_error_invalidaccess would be better, since what is really being indicated
is that the copied information is not changeable.
>> If the FontType of pfont_new is not compatible with the FontType of
>> pfont_old, return gs_error_rangecheck.
> I'm curious about the choice of 'gs_error_rangecheck' here since
> it does not feel like a 'range' issue?
>> glyph_new may be gs_no_glyph, indicating that *pfont_new
>> consistently uses the same glyph identifiers as *pfont_old (and
>> hence glyph_old should be used for pfont_new as well).
>> If glyph_old has 'pieces' (e.g., Type 1 'seac' glyphs, TrueType
>> composite glyphs), then if glyph_new is not gs_no_glyph, return
>> gs_error_rangecheck (even if glyph_new is the same as glyph_old); if
>> glyph_new is gs_no_glyph, copy the pieces as well.
> Why the choice gs_no_glyph as opposed to say GS_COPY_GLYPH?
Currently there is only one distinguished out-of-range value for gs_glyph,
gs_no_glyph. I would prefer not to introduce a second one.
> Why error out if the glyph is composite? Would it be possible for the
> routine to recurse and load the subglyph(s)? If the new font is using the
> same glyph IDs as the old font then the IDs for the subglyphs is known.
That is precisely the motivation for the option of glyph_new == gs_no_glyph.
- If the client of copy_glyph *is* using the same glyph numbering in
the copy as in the original, the client passes glyph_new =
gs_no_glyph to indicate this, and the implementation of copy_glyph
can then copy composite glyphs, using the same glyph numbers for
- If the client of copy_glyph is *not* using the same glyph
numbering in the copy, the implementation cannot copy sub-parts,
because it has no way to know what glyph numbers to assign to
> If not how would a font with composite glyphs be copied?
The client must call the glyph_info procedure of the font, setting
GLYPH_INFO_NUM_PIECES and GLYPH_INFO_PIECES, in order to find out the glyph
numbers of the sub-parts, and then copy them explicitly (presumably
modifying the composite glyph's definition to refer to those pieces, however
that is done for the particular FontType).
I hope this clarifies the intention of this part of the proposal. If not,
please feel free to ask for more explanation.
L. Peter Deutsch | Aladdin Enterprises | 203 Santa Margarita Ave.
ghost at aladdin.com | http://www.aladdin.com | Menlo Park, CA 94025
No government censorship of software! Oppose the CBDTPA! www.eff.org
More information about the gs-devel