Re: [Devel] Ready for 2.0.8

[David Turner]

Hi Keith,

Keith Packard a écrit :
> 
> Around 11 o'clock on Feb 8, David Turner wrote:
> 
> >  A - I'd prefer having a "FT_Get_First_Char" function, instead of
> >      calling FT_Get_Next_Char(0) to retrieve the first character
> >      code in a charmap..
> 
> There is a simple canonical sequence of code to retrieve the first
> character:
> 
>         if (FT_Get_Char_Index (0))
>                 first_char = 0;
>         else
>                 first_char = FT_Get_Next_Char(0);
> 
> I didn't add this as a function inside FreeType as it seemed "too simple".
> However, it is a programmer trap of sorts.
>
I don't think it's "too simple" in my opinion, especially if you're thinking
about the typical developer that doesn't dig font technology too much.

Moreover, the code becomes even a bit more complex when you want to deal
with the (possible, though unlikely) case of an empty charmap.. with the
potential for even more confusion..


> >   B - I'd prefer that the "FT_Get_First_Char" and "FT_Get_Next_Char"
> >       functions be able to return the glyph index corresponding to
> >       the character code as well, like:
> 
> Why is this useful?  You can simply call FT_Get_Char_Index on the return
> value.
>
It's useful for two reasons, at least:

  - first, it correspond to another common usage of charmap enumeration,
    since some programs need to retrieve (charcode,glyph_index) pairs to
    build custom mappings (for example, to keep it outside of a FT_Face
    object).

    It's also not much to add to the internal code, since you can
    normally access the glyph index directly within the implementation
    of FT_Get_Next_Char


  - the second reason is that it provides much better semantics, since
    you don't need to do special checks for charcode 0 or for emptiness.
    Instead, a simple enumeration loop can be written as:


        char_code = FT_Get_First_Char( face, &glyph_index );
        while ( glyph_index != 0 )
        {
           // .... do something with (char_code,glyph_index)

           char_code = FT_Get_Next_Char( face, char_code, &glyph_index );
        }

    In my opinion, that's an order of magnitude simpler to understand and
    use for any kind of developer. And it has the advantage of correctness
    as well :o)

> That's reasonable; we clearly need a bit more discussion on precisely
> how the API should work, and whether small changes would make significant
> improvements in what other applications could do with this.
> 
> As you know, my only intent was to be able to rapidly walk the encoding
> table to generate an accurate mapping of mapped values.  This API is
> sufficient for that work; I've reduced a 10 minute activity to about 2
> seconds.
>

I know that I probably look rather picky regarding API additions these days,
but that's mainly because I'm currently re-organizing stuff within the library,
and the high-level API limitations simply strike me as extremely annoying
in many cases.

Many of the additions we've made in the past were not very well though out,
we simply wanted "something that works" at the time.. it's simply time to
be a bit more skeptical before adding anything new..
 
Regards,

- David