[ft-devel] Re: Report a bug.

[Werner LEMBERG]

> > FT_Get_{First,Next}_Char are walking over cmaps, not over glyph
> > indices.  Except for subsetted CID-keyed CFFs (which use CIDs
> > instead of glyph indices), the range for glyph indices is *always*
> > contiguous.
>
> Ok, so the problem is that this one program needs to walk all the
> glyphs and dump them out, regardless if they are in the current
> cmap?

Yes.  This is true especially for CID-keyed fonts currently, since
FreeType, unfortunately, doesn't have support for (Adobe) CMaps (yet)
-- one of the biggest missing pieces in FreeType.

> To a normal program, glyph indexes are meaningless without some kind
> of context.

They might be useful for caching.

> Personally I would hate to see "number of glyphs" become a
> meaningless "maximum glyph index" for a single programs benefit, but
> I suppose number of glyphs is meaningless to a normal program as
> well.

Where's the problem?  For CID-keyed fonts, you don't have direct
access to glyph indices anyway since you access the fonts by CIDs
exclusively.  For all other fonts, the introduction of the
`FT_IS_CID_KEYED' macro should solve the issue: If it evaluates to
false, the glyph index range is contiguous.  Otherwise, it might
contain holes, this is, you have to properly ignore the
`FT_Err_Invalid_Argument' error which FT_Load_Glyph() is returning in
such a case.

BTW, the very change is just a single line:

  --- cffobjs.c.old       2007-07-06 22:37:58.000000000 +0200
  +++ cffobjs.c   2008-03-30 20:56:35.000000000 +0200
  @@ -446,7 +446,7 @@

           /* compute number of glyphs */
           if ( dict->cid_registry != 0xFFFFU )
  -          cffface->num_glyphs = dict->cid_count;
  +          cffface->num_glyphs = cff->charset.max_cid;
           else
             cffface->num_glyphs = cff->charstrings_index.count;

> -> Except for subsetted CID-keyed CFFs (which use CIDs instead of
> -> glyph indices), the range for glyph indices is *always*
> -> contiguous.
>
> which can be reduced to
>
> -> The range for glyph indexes is *usually* contiguous
>
> which to a normal application might as well be written as
>
> -> The range of glyph indexes is unknown

Just think of an application which wants to support its own caching;
to support all possible cmaps of a font it uses glyph indices to walk
over the complete font; it's good to know that this can be done with a
simple loop using `num_glyphs'.

> Is the issue you don't want to change the API?

I *must not* change the API.

> Otherwise I would think a FT_Get_First_GIndex/FT_Get_Next_GIndex
> might be a more general solution.

This isn't a change but an addition :-)

However, I don't see a need for it, especially because the concept of
`first' and `next' are meaningless for glyph indices except in the
sense of an iterator.  In particular, FreeType reorders glyph indices
for some fonts to assure that glyph index 0 always maps to the .notdef
glyph (or its equivalent).

> Let it also return a reverse lookup in the CMAP (when one occurs)
> and it would be beneficial to me at least.  I already have to build
> such a table for a number of reasons.

This is a very special thing: Building a reverse lookup works only
under the assuption that there is a one-to-one relationship between a
cmap value and a glyph index.  In most cases, this is not true.


   Werner