Re: some more issues with the new API

[Stefan Seefeld]

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.
> 
> Then, you could use the face object as a glyph bitmap or outline
> factory..

Ok. This means that the semantics of Glyph shifts quite a bit. It
means that Glyph isn't merely an abstract type which knows how to
render in a couple of ways (i.e. creating outlines and rasters of
itself) but that it *is* one of those rendered forms. Thus, having
Face create Glyphs (as in factory) means that Glyph is still an
abstract type with a polymorphic 'render' method. I could use a
visitor like pattern to let the device and glyph negotiate the
actual rendering process...

Hmm, having seen that this is indeed *not* identical to the 'GlyphSlot'
of the Face, I'm still wondering why this slot is necessary.
Given my GLyph 'use case' above, it seems a GlyphSlot is the Glyph 
factory then. I'm still uneasy about the idea to hold the GlyphSlot
within the Face. As I said, the threading problem is just a hint
that something is wrong.

> a "slot" is factory for glyph bitmaps and outlines. Before doing so, you
> must load a glyph image in the slot.. (the image isn't necessarily a bitmap
> or an outline, by the way).

Fine. Let's call it GlyphFactory then. And yes, it is abstract, it completely
hides how it generates glyphs. Also, the fact that the 'image' isn't necessarily
bitmap or outline just underlines the point that Glyph is still abstract, i.e.
you should not expose internal data with it but rather provide a function which
can render it.

> As a convenience, you can directly access the image's data in the slot
> through face->glyph->bitmap and face->glyph->outline, when their format
> is respectively ft_glyph_format_bitmap & ft_glyph_format_outline..

Well, I can live with that even though I'd like to hide this direct access in
my API :)
Again, the point is not to access the bitmap from the glyph (if ever the glyph
has a notion if what a bitmap is) but to access the glyph (slot) from the face.
What I propose is all but dramatic. Just un-encapsulate the slot data. It's
still the Face which creates and loads the slot. It's just that the data is
living elsewhere and should be passed to the face when it should be loaded.
I'll call it GlyphFactory here:

FT_Face face;//...
FT_GlyphFactory factory;
FT_Glyph; // contains the bitmap, outline or other data
          // and a function pointer which is able to render these data

FT_LoadFactory(face, factory); // instead of FT_LoadGlyph

Once this call is finished, you own the factory, even though you might
not be able to deal with it without consulting the face again.

> a "glyph" object is normally metrics+bitmap or outline. Its exact structure
> is completely application-dependent, in my opinion.. You can however easily
> generate them from a slot.. and FreeType provides the types FT_Bitmap and
> FT_Outline that you can use directly if you want to..

Fine.

_______________________________________________________
              
Stefan Seefeld
Departement de Physique
Universite de Montreal
email: address@hidden

_______________________________________________________

      ...ich hab' noch einen Koffer in Berlin...