Re: Musing about the new API

[David Turner]

Hi Peak,

Pavel Kankovsky a écrit :
> 
> The recent debate made me look at the new API closer...
> for the first time. Of course, an immediate outburst of (hopefully
> constructive) criticism was unavoidable. :)
> 
> 1. Why is FT_Size called FT_Size instead of FT_SizeSlot? (It is "a
> container where resolution and pointsize dependent data of a give face
> can be loaded.")
> 
No particular reason, I agree :-)

> 2. I am afraid FT_New_Size and FT_New_GlyphSlot are next to useless. Sure,
> you can create new sizes and new glyphs...err...glyph slots but unless you
> use them in a strictly LIFO order (create size, create glyph slot, load
> glyph, use glyph, destroy glyph slot, destroy size), you would have to
> mess with FT_Face->size and FT_Face->glyph to be able to use them and that
> would be very very ugly.
> 
A simpler alternative is to provide a FT_Load_Glyph_Ext( glyph, size, index, 
flags )
function that accepts a glyph slot and a size object as parameters, and you're 
done.
However, this function was removed (it was present in the initial design).

Again, the reason why there can be more than one glyph slot per face was
initially to allow concurrent glyph loading. However, supporting this feature
introduced some sensible complexity in the design and I prefered to forget
about threads..

On the other hand, when the FT_Load_Glyph_Ext function is available, the ability
to use several FT_Size objects per face is of great help to reduce the memory
requirements of a font manager/glyph cache/text layout package.

> 3. Things like FT_GlyphSlot->next should not be exposed to the user.
> (Supplementary question: why do sizes have their FT_Face->sizes_list and
> glyph slots do not?) I agree it is quite annoying to create and have to
> use an access "method" for every stupid field of the structure but the
> other extreme is not perfect either.
> 
Because FT_GlyphSlot->next is deprecated, while FT_Face->sizes_list will
stay there. I can't explain it easily, but I hope to write, after the FT2
release, a text layer/font manager on top of FreeType 2 that will clearly
show why everything is in place as it is currently..

> 4. I find the semantics of FT_Open_Args and related functions somewhat
> confusing. In particular, I am afraid that depending on the place where
> FT_Open_Face fails, the stream (supplied by the user of created
> automatically) is either destroyed or left alone.
> 
OK, I agree. All I want is to be able to open a face in several ways
without having a huge number of fonts. What do you think of adding
a bit flag mask which indicates which fields should be read to build
the input stream and select the driver ?

> Some suggestion:
> 
> ad 2.+4. I think "the convenience layer" of the API should be clearly
> separated from the rest of the library and its operations should be built
> on the top of "general-purpose" operations.
>
Agreed, but I think that the API will provide new functions that directly
return a glyph image ( a bitmap, or an outline ). The glyph slot will
still be there, but hidden to most applications..

> ad 3. Ideally, private fields should be hidden in the same way
> driver-specific fields are hidden. Or at least, such fields should be
> moved to the end of their struct's not to break binary compatibility when
> they change (and marked as private clearly).
>
OK, they'll be moved to the end of the structs. I do not want to make several
layes of encapsulation because it really is painful in C (there are some places
where a C++ syntax is good :-)

- David

> --Pavel Kankovsky aka Peak  [ Boycott Microsoft--http://www.vcnet.com/bms ]
> "Resistance is futile. Open your source code and prepare for assimilation."