[gs-devel] Proposal for changing semantics of
gx_font_stack_item_t::index (bug #690834)
masaki.ushizaka at artifex.com
Thu Nov 19 00:24:29 PST 2009
On 2009/11/19, at 0:49, Ken Sharp wrote:
> At 22:42 18/11/2009 +0900, Masaki Ushizaka wrote:
>> fstack.items is a rootfont. fstack.items[1 .. fstack.depth-1] are
>> intermediate composite fonts. And fstack.items[fstack.depth] is a
>> base font or a CIDFont. These are aligned in
> I have no objection to the patch, what I see looks sensible, and is
> the way I thought it worked anyway....
> I do have some questions about the existing scheme for my own
> education though if you don't mind answering them.
> fstack.items.font is a root font (type 0 composite font)
> currently fstack.items.index is always 0.
> You describe fstack.items[1 .. fstack.depth-1] (presumably
> the .font member ?) as 'intermediate composite fonts' are these type
> 0 composite fonts, or base fonts of some kind, or can it be either ?
Yes, I meant '.font' member. 'Intermediate composite fonts' are just
usual FontType 0 composite fonts. I said 'intermediate' because some
of us may not aware that composite fonts can be nested up to five
> fstack.items[fstack.depth], again presumably the font member, is a
> base font or CIDFont. I can see what this means for CIDFonts, what
> is meant by a 'base font', a type 0 or something else ?
The 'base font' is a red book terminology. PLRM3 p. 321, "Fonts of
type 1, 2, 3, 14, and 42 are called base fonts." This description may
not be sufficient. In Level 2, 'base fonts' are the all fonts but
composite fonts. PLRM2 p. 265, "Type 0 is a composite font composed
of other fonts called base fonts, organized hierarchically." That is,
the fonts have actual glyph descriptions. It actually includes
Adobe's secret font types like 4, 5, 7... I have been believing that
the CIDFonts are also base fonts but PLRM3 distinguish it from base
font. In PS3, there are three font classes: composite font, base font
and CID keyed font. The CID keyed font is not a base font probably
because Adobe's original plan was to replace all base fonts with
>> Currently, 'index' member is used:
>> For n=0: fstack.items.index == 0 (not used)
>> For n=[1 .. fstack.depth]:
>> fstack.items[n].index == font number used in
>> (fstack.items[n-1].font.data.FDepVector[indexed by
>> fstack.items[n].index] == fstack.items[n].font)
> So this implies that each member of fstack.items[1...fstack.depth-1]
> is potentially a composite font with its own array of descendants ?
Each member of fstack.items[1.. fstack.depth-1].font is always a
composite font, as well as fstack.items.font. Its descendant fonts
can be accessed by casting it to 'gs_font_type0' and
accessing .data.FDepVector. This real code would be:
gs_font_type0 *pfont0 = (gs_font_type0 *)fstack.item[n].font;
+1].index]] == fstack.item[n+1].font);
> It also seems to imply that when a composite font has composite
> descendants, the descendants have FDepVector arrays whose members
> are elements of the fstack array ?
Each member of fstack.items[0.. fstack.depth-1].font is a composite
font and its descendant fonts can be accessed by described above. But
contents of FDepVector are references to another gs_font objects.
'fstack' is an array describing a single path of fonts those ware
selected to 'show' current glyph. gs_type0_next_char_glyph() is
called for each glyph to know if selected descendant font path has
been changed for next glyph.
> I'm puzzled as to the way these fonts are laid out, and would like
> some education on the subject, pictures might be required ;-)
I am still learning things here. Those are the things I somehow
managed to figure out so far.
More information about the gs-devel