[gs-devel] Proposed new gs_font procedures

[Igor V. Melichev]

Peter,

> From: gs-devel-admin at ghostscript.com on behalf of L. Peter Deutsch
> [ghost at aladdin.com]
> Sent: 24 ьр  2002 у. 05:57
> To: gs-devel at ghostscript.com
> Subject: [gs-devel] Proposed new gs_font procedures

My remarks below were done with no dependence on the
"next snapshot of new pdfwrite text code" submitted
recently. I consider "Proposed new gs_font procedures"
as a specification of the new interface. Therefore
my remarks to be addressed to both the interface and the specification.

>	int (*copy_font)(gs_font *pfont_new, int members,
>			 const gs_font *pfont_old);

I'm not clear, what happens if pfont_new represents a CID fonts.
In this case there exist descendant instances of gs_font.
Should copy_font (a) to be applied to each descendent font by a client,
(b) does it applies recursively, or (c) does a single activation
of copy_font accesses and copies all descendents ?
Probably you suppose that your specification defines
the client's view only, and that CID font looks as a black box with
pfont_new handle, so we choose (a). Please clarify.

> 	If COPY_FONT_GLYPHS is set, copy all the glyphs of the font;
> 	otherwise, the new copy has no glyphs defined.

Probably it should ever copy .notdef/CID0 glyph.
Note that .notdef may be unaccessed by a document, but should present
in the output embedded font.

> 	If COPY_FONT_ENCODING is set, copy the encoding of the font (if this
> 	is a meaningful concept for the font: it isn't for CIDFonts, but it
> 	is for TrueType fonts, where the 'cmap' table provides this
> 	function); otherwise, the new copy has no encoding defined (and
> 	therefore can only be used with glyphshow or the equivalent).

IMO 'cmap' isn't same as Encoding.
Embedded Type 42 fonts (for both PS and PDF) don't use cmap.
They use Encoding and Charstrings instead.

Perhaps when GS interprets a PS document with a True Type font
substituted to a PS font, GS first uses the 'cmap'.
Details of the conversion of the True Type font to PS font
may be different for Type 42 and CIDFontType 2 (the latter
depend on gs-cjk team), but I guess that in any case
we first convert cmap to PS structures in the interpreter,
than copy PS structures in pdfwrite. Therefore I guess
that the mentioning of cmap in your spec isn't relevant,
and to be replaces with an explanation like I did here.


> 	int (*copy_glyph)(gs_font *pfont_new, gs_glyph glyph_new,
> 			  gs_font *pfont_old, gs_glyph glyph_old)

Not clear what happens with composite glyphs,
which may happen in Type 42 and CIDFontType 2.
Note that the descendant subglyphs may form a random acyclic oriented graph
rather than a tree, so the copying entire graph needs auxiliary storage
for marking nodes were copied.

Again, please clarify about cases (a), (b), (c) mentioned above.

>  If *pfont_new already has a definition for glyph_new,
>	return gs_error_rangecheck.

Not sure that it is good. I'd define :
an attempt to copy same glyph at second time is being ignored;
an attempt to replace a glyph yields rangecheck.

> "Compatible with" means "the
> 	same as", except that Type 1/2 fonts are mutually compatible with
> 	CIDFontType 0 CIDFonts, and Type 42 (TrueType) fonts are mutually
> 	compatible with CIDFontType 2 CIDFonts.

This isn't clear. I realize that we can easy copy a restricted
set of glyphs from a CID font to a non-CID font.
But copying them backwards needs a choice of descendent font
for CIDFontType 0. The choice (1) depends on CID character collection,
which is language dependent, (2) depends on the narrow/wide/proportional
feature of the source font, (3) may fail due to incompatibility
of source character set with destination character collection
(for instance, DingBats to Japan1).

Besides that, do we intend to copy from Type 1 to Type 2 ?