Re: some more issues with the new API

[David Turner]

Just van Rossum a écrit :
> 
> David Turner wrote:
> >It's hard to explain in a few lines, but I think that exposing the
> >FT_Size and FT_GlyphSlot objects in a high-level wrapper is simply
> >not a good idea. These things should be kept internal and not
> >exposed in the HL-API.
> 
> Ok, but then: how do you position a glyph? How do you rotate it? These are
> methods of the outline object, but how do I get to the outline if I can't
> get at the glyphslot? A new API?
> 
Create the Glyph, BitmapGlyph and OutlineGlyph classes in your high-level
wrapper. Glyph only contains fields for metrics + bearings..

Then, implement the following methods to the Face class:

  face.glyph_format         : returns the format of the glyph image in the
                              slot..

  face.get_glyph_bitmap()   : returns a GlyphBitmap in all cases for the image
                              currently in the glyph slot..

  face.get_glyph_outline()  : returns an GlyphOutline when there is one 
available
                              in the glyph slot, nil otherwise.

Then, translating, transforming, etc.. are methods of GlyphOutline, not Glyph,
and you can implement them with the FT_Outline_xxxx functions..

You can also provide a method of GlyphOutline to produce the equivalent
GlyphBitmap after transformation (by calling FT_Outline_Get_Bitmap)..

Does it sound too verbose, complex, or restrictive to you ?

> (I take it you don't mind the non-reentrantness of the FT_Load_Glyph()
> function?)
> 
Actually, the initial design of FreeType 2 was re-entrant (but you should
dig a very old beta to see this). For example, FT_Load_Glyph took
a "slot" and a "size" as parameters.

Then, each thread was able to provide its own glyph slot where the
glyph image would be loaded from the font file. They could also use
the same "size" during the concurrent calls (and eventually share the
same "face" too).

Actually, the reason why there can be more than one slot per face is
precisely to allow concurrent glyph loading !! Hence, TT_New_Glyph /
TT_Done_Glyph, etc..

However, as I progressed in the design and implementation, and after
producing quite a lot of code that used the library, I went to the
following conclusions:

  - the FT 1.x API is powerful, but clearly too complex for most uses.
    I thus re-designed the FT2 API to considerably simplify the number
    of function calls required to perform the common tasks (no need to
    create your own slot and size, however, FT_New_Size & FT_New_Glyph
    still exist, automatic selection of a Unicode charmap when available,
    etc..).


  - Developing fine-grained thread-safety imposes severe restrictions
    on the design of font drivers, and could complexify things greatly
    due to the dependencies between faces, sizes and slots, and I wanted
    to keep the design small and simple (reduces debugging time).

    Also, I want that writing a new font driver remains relatively easy,
    and this couldn't be the case with thread safety in mind..


  - Developing coarse-grained safety is easy (you could put a mutex on
    each font driver), but what's the point of putting it in the library
    when you can simply ask for client applications and libraries to
    serialize access themselves (thus avoiding portability issues related
    to synchronization). That's why there is no FT_Mutex defined in
    "include/ftsystem.h". I guess this means that you will need to put
    such a mutex in a C++ or Python wrapper..

I would like to give you specific examples that show how complex and weird
the code would result if we wanted to integrate thread-safety in the design.
Sometimes, not all goals can be reached, and I clearly favored simplicity
and flexibility in the current design..

Hope this helps,

- David

> Just