Re: some more issues with the new API

[Stefan Seefeld]

David Turner wrote:

> Not exactly, there are a lot of things in a glyph object that a client 
> application
> will never see (and will never need to see :-). A bitmap or an outline is 
> simply
> one view of the content of a glyph slot..
> 
> The glyph slot can be seen as bitmap/outline factory if you really want to
> speak in OO terms, however there is no reason to decouple it from its parent
> FT_Face..

yes there is. The reason is that a face can hold quite a lot of different glyph
slots (factories). I wouldn't care so much if it was used always to create 
glyphs
(glyph bitmaps, outlines etc.) *immediately* after the slot has been loaded:

FT_Face face;
FT_LoadGlyph(face, ...);
draw_outline(face->glyph->outline);

but this is not enforced by the API, so there is a pitfall.


> Actually, it's not a glyph, but a "glyph slot", i.e. a place where glyph
> images (whichever their format) can be loaded. Once a glyph image is loaded,
> it can be later converted into a bitmap.
> 
> The FT2 API exposes parts of the glyph slot data, in order to access the
> bitmap or outline data directly, but this is essentially for purpose of
> efficiency.

I agree. Yet I think this is a nice example of 'premature optimization'.
I'm sure we can come up with a perfectly well behaved OO design and yet
preserve *all* of your efficiency considerations. For example we can avoid
'deep copies' if the data are allocated by the Face and just handed over to
the GlyphFactory which in turn hands them over to the Glyph (Outline, Bitmap
etc.). The point is really about ownership. All the rest, polymorphism through
function pointers etc. are not touched at all.

> Actually, the load flags indicate which kind of image you want to load in
> the glyph slot for a given glyph index, it indicates which _view_ of the
> glyph index you want to load in the slot. However, this image can be later
> rendered into something different..

Ok, expressed in my words, you create a GlyphFactory with a hint at what
Glyph type you are interested in so the Factory can already cache the data
it is probably handing over to the Glyph it generates later on.

> To be able to produce a device-dependent glyph bitmap or outline, you really 
> need
> the corresponding FT_Face and FT_Size, simply because these objects contain
> control data that is required to perform the scaling and hinting necessary to
> produce the final output..

Fine. The Glyph (factory) can hold a pointer to it's Face...

> Of course, we could find a way to duplicate this data in the glyph object, but
> this would be properly un-necessary duplication.

Agreed.

> The control data in a FT_Face
> or FT_Size is format dependent, and can take several kilobytes for TrueType
> fonts, not something that you want to cache easily.. and not something that
> you can easily decouple on a glyph-by-glyph basis..

Right. Decoupling doesn't mean total independence. But the question is really
what properties make up a given object. While the above 'control data' are all
characteristic of a given face, a 'current glyph' is not and can therefor
easily be factored out. Note also that a face is still a property of a glyph,
so the glyph can (should) reference it's parent face.
To stress it again, we don't decouple glyph and face, we just make it oneway
(glyph depends on face), as Just already pointed out.


> don't take me wrong, but I believe that you're applying OO principles to the 
> wrong
> problem space..

That's possible. I already had a hard time when I tried to wrap openGL into
an OO API :) What we finally did is preserve the semantics of a state machine
with lots of attributes all reflecting the current state.

However, 'current color' indeed is a state and it would be annoying if I'd need 
to
pass it (may be encapsulated in a 'Graphics Context') to each drawing call. A 
rendering
pipeline is indeed a very different animal...

> > indeed. That's because size is used to create a glyph from a face. Size is 
> > not an
> > inherent property of the face. So it should be given as an argument to the
> > FT_Load_Glyph function but not contained in the face. The fact that it is 
> > not
> > MT safe is just a symptome for the more general problem of not optimally 
> > decoupled
> > types.
> >
> Again, the control data of a FT_Size object can be very complex and large, 
> and it
> would be properly impractical to re-compute it every time we load a glyph, 
> hence
> the "FT_Size" objects within the FT_Face.

What is size then ? Is it a property of face ? Is it a property of glyph ?
If it is too complex to copy but you want to hide it somewhere else, why not 
simply
provide accessor functions, operating via the Glyph ?

FT_Glyph_Size(glyph) { return FT_compute_size_from_wherever_you_want(glyph, 
glyph->face);}


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

_______________________________________________________

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