[gs-devel] Proposed new gs_font procedures
stefan at artifex.com
Tue May 28 08:11:36 PDT 2002
A few questions.
Why is this required?
In particular was the behavior already there but in pdfwrite and now you
moving the responsibility or is this a new behavior?
By copy do you mean deep copy?
What is the usecase for with glyph data?
What is the usecase for without glyph data?
"L. Peter Deutsch" wrote:
> The new, simpler pdfwrite font code requires the ability to copy a font,
> with or without its per-glyph data (outlines and metrics), and to copy
> individual glyphs afterwards. Here is the proposed definition of the new
> "object" procedures.
> #define COPY_FONT_GLYPHS 1
> #define COPY_FONT_ENCODING 2
Style, I prefer enums.
What does it mean to copy the encoding but not the glyphs?
I assume that pdfwrite is the only caller of (*copy_font). Can you
describe how it uses this in particular when does it copy font alone
and fonts with glyphs, fonts with glyphs & encoding?
Does the client have control over how this is used?
How does the incremental font case work where glyphs and encodings are
> int (*copy_font)(gs_font *pfont_new, int members,
> const gs_font *pfont_old);
> Finish creating a copy of the font referenced by pfont_old.
> pfont_new is a verbatim copy of the top level of the structure,
> with a few minor cleanups (see below).
Finish implies there is a pre step. Describe the usage.
> The copy_font procedure must always copy the font-wide metrics and
> other information covered by the FONT_INFO_ flags that can be passed
> to the font_info procedure; it must optionally copy additional
> information as indicated by the members argument.
> If COPY_FONT_GLYPHS is set, copy all the glyphs of the font;
> otherwise, the new copy has no glyphs defined.
> 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).
> int (*copy_glyph)(gs_font *pfont_new, gs_glyph glyph_new,
> gs_font *pfont_old, gs_glyph glyph_old)
> Copy the definition of glyph_old, including any associated metric
> information, from *pfont_old to *pfont_new, associating it with
> glyph_new. If *pfont_new already has a definition for glyph_new,
> return gs_error_rangecheck.
> If the FontType of pfont_new is not compatible with the FontType of
> pfont_old, return gs_error_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.
> 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.
> Default implementations of these procedures will be provided,
> gs_no_copy_font and gs_no_copy_glyph, which will always simply return a
> rangecheck error. If pdfwrite gets an error from a copying operation, it
> will default to turning the respective font or glyph into (a) bitmap(s).
> Note that these procedures are REQUIRED. Any code that creates instances of
> any subtype of gs_font (currently gs_font_type0, gs_font_type1 (also used
> for Type 2), gs_font_base (used for Type 3), gs_font_type42, gs_font_cid0,
> gs_font_cid1, gs_font_cid2) MUST provide some implementation for these
> procedures (although it may be the _no_ implementation that always returns
> an error). Code that provides additional data (such as the FontInfo,
> Metrics, CDevProc, etc. structures in PostScript) MUST provide its own
> implementation of copy_font and/or copy_glyph that will copy this data: this
> may affect all of the .buildfont operators (0, 1, 2, 3, 4, 9, 10, 11, 32,
> Note that clients should never call copy_font or copy_glyph directly: they
> should always call gs_copy_font or gs_copy_glyph.
> int gs_copy_font(const gs_font *pfont_orig, gs_memory_t *mem,
> int members, gs_font **ppfont_copied);
> int gs_copy_glyph(gs_font *pfont_new, gs_glyph glyph_new,
> gs_font *pfont_old, gs_glyph glyph_old)
> gs_copy_font allocates the copy, copies the old contents into it verbatim,
> performs the cleanups listed just below, calls the copy_font procedure, and
> frees the copy if the copy_font procedure fails. The cleanups are:
> - Clear the next and prev members.
> - Set the memory member to the 'mem' argument of gs_copy_font.
> - Clear the notify_list.
> Note that the arguments of gs_copy_font are in a different order from those
> of the copy_font virtual procedure.
Why are they different?
> Note that since copy_font procedures aren't responsible for the allocation
> and verbatim copy steps, they can usefully call the "superclass" copy_font
> procedure. For example, the copy_font procedure for CIDFontType 2 CIDFonts
> can probably call (if it isn't the same as) the copy_font procedure for Type
> 42 (actually TrueType) fonts.
> gs_copy_glyph simply calls the copy_glyph procedure, since there is no
> useful generic checking or function that it can provide.
> I feel extensions of this kind to a core object's procedure set require very
> careful scrutiny. However, I am also at a point where I will need to write
> code to use this procedure in the very near future. I would really like
> feedback on this proposal within a week (by the end of next Wednesday,
> 5/29). I would especially like feedback from the PCL development team,
> since this proposal may create additional work for them: alternative
> proposals that reduce or eliminate this, while meeting the requirements of
> pdfwrite, would be welcome.
> Thanks -
> 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
> gs-devel mailing list
> gs-devel at ghostscript.com
More information about the gs-devel