[gs-devel] Proposed new gs_font procedures

[L. Peter Deutsch]

Brian,

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?

See above.

>>         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
	  the sub-parts.

	- 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
	  them.

> 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