[ft-devel] Re: Report a bug.

[Deron Kazmaier]

Werner LEMBERG wrote:
> > Please forgive me ignorance, but why would the normal
> > FT_Get_First_Char/FT_Get_Next_Char not work for this?  Perhaps I
> > missed the part in the documentation which states that no glyph
> > index will exceed the num_glpyhs count, but I have always treated
> > glyph indexes as a discontinuous sequence.
> >     
>
> 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.
>
>
>     Werner
>
>   

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? To a 
normal program, glyph indexes are meaningless without some kind of 
context. 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.

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


Is the issue you don't want to change the API? Otherwise I would think a 
FT_Get_First_GIndex/FT_Get_Next_GIndex might be a more general solution. 
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.

Just trying to contribute in some small way. Even if you think I'm off 
base, maybe the discussion will help you reach a better conclusion. It 
is already a great library, and I'm thrilled to have it.

Deron