Re: some more issues with the new API

[Just van Rossum]

I wrote:
> 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?

David Turner wrote:
>Create the Glyph, BitmapGlyph and OutlineGlyph classes in your high-level
>wrapper. Glyph only contains fields for metrics + bearings..
[ ... ]

Well, there's one thing I don't understand at all: Why wouldn't you want
such an API at the C level? I would very much prefer to just convert a C
API into a thin OO wrapper. What you suggest is for each higher level
interface to reinvent the wheel, whereas I think the C API should provide
that functionality, so that *any* client (Python, C++, C, whatever) can use
it.

(Of course, what I'd *really* like to see is a truly higher level C API,
one that can render entire strings: that's what most users will need! A
string of text, a start position, a transformation, and blast it onto a
bitmap. Optionally specifying OT layout features.)

[ ... ]
>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.

That's because it's too low level, not necessarily because of the API
itself. The FT2 API is indeed simpler, but it's still low level: people
will still have problems with it (like I am having now ;-).

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

Ok, so maybe we can just these instead of using the default slots. However,
there are still problems. From freetype.h:

   FT_New_GlyphSlot
      It is sometimes useful to have more than one glyph slot for a
      given face object.  This function is used to create additional
      slots.  All of them are automatically discarded when the face is
      destroyed.

So the *face* is still in charge, making it hard to do automatic
deallocation. And:

   FT_Done_GlyphSlot
      Destroys a given glyph slot.  Remember however that all slots are
      automatically destroyed with its parent.  Using this function is
      not always mandatory.

"Not always"? When is it? The semantics are blurry, to say the least.

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

If you keep less state in the face object, but pass things around, writing
a thread safe driver shouldn't be any more trouble than it is now, would
it? Where exactly do you see the problems in writing a thread-safe driver?

Thanks for your insight in history of the design of FT2! Much appreciated.

Just