Re: some more issues with the new API

[David Turner]

> 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.
>
I believe that my opinion of the subject is biased by the fact that
the first text service I developed on top of FreeType 2 didn't need
anything more than the current API. It provided all the normal text
services (as the one you describe below), without ever needing
higher-level classes.

Of course, it was developed for FT2, and FT2 was developed for it,
so there was tight integration, and one of the design requirements
was that the code had to be small, and use few memory, which it did..

However, your remarks make it clear that the API might be a bit too
low level for most users, and needs a revamp..

> (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.)
>
It all boils down to what kind of service you want to provide. For now,
I'll stick to "font service" for FreeType 2.

> [ ... ]
> >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 ;-).
>
Well, the idea was to reduce the number of function calls used by most
uses, not to make it more abstract ;-) It's simpler than FT 1.x for
approximately the same features, while being more general..

> >    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.
> 
Yes, I'm sorry if this blurry. I'm still convinced that these details
should not be exposed to a high-level interface. We'll have to move
these fuctions to internal header files..

> >  - 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?
>
I have not all details in mind, but I believe it all related to the amount
of sharing between objects and drivers. Thread-safety meant either duplicate
most data or make the design more complex. And the first option wasn't really
welcome..

There were also some complexities introduced by the handling of the TrueDoc
format, which, for example, would make the implementation of thread-safe
multiple-master drivers difficult if you don't want to copy huge amounts
of data..

I'd really like to give a simple explanation, though.. :-(
Now, for the serious stuff, how can we make the FT2 API a bit more abstract.

Should we introduce the FT_Glyph / FT_GlyphBitmap / FT_GlyphOutline types
(moving FT_GlyphSlot under the hood) ?

We can also specify a transform as in FT_Set_Transform in order to generate
transformed outlines/bitmaps directly ?

I still don't think that users should see the FT_Size and FT_GlyphSlot
objects. These concepts are deeply rooted to the way font files are
structured and how font drivers are able to "sub-class" the root types..

Any comment ?

- David

- David

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