Re: some more issues with the new API

[David Turner]

Hi again,

> 
> the sentence ends here so I'll try rephrasing :)
> What I meant is that the way I would design a Glyph class depends on what its
> role is (naturally). If it contains the outline data, it has an accessor to
> get it. If it does not, but can create it, it would have a factory method, 
> i.e.
> a method returning a *new* Outline object. The difference is only ownership.
> 
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..

> Ok. Now I'v read a bit the embedded docs and I'm somewhat confused about what
> glyphs are. It seems a Glyph is loaded already together with some 'drawable'
> type (bitmap or outline) to be used in the rendering process.
> Is there any advantage in combining these steps into one ?
> 
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.

> > FT_Get_Glyph_Bitmap() doesn't create a bitmap: the FT_Bitmap needs to be
> > provided by the caller. So it's not a return value. I think (but am not
> > 100% sure) that the bitmap field of the FT_GlyphSlot objects is meant for
> > embedded bitmaps, and not for rendered outlines. That would give the bitmap
> > field the exact same status as the outline field.
> 
> indeed. As the docs state, you load the glyph with a set of flags indicating
> whether you want a outline and or bitmap generated for it. So the above
> function is probably just supposed to copy the bitmap into the user provided
> one.
> 
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..

> > Also, I don't quite understand your argument why a glyph shouldn't contain
> > a reference to an outline (or embedded bitmap).
> 
> Because the Glyph graphic (vector or raster) is device dependent. The glyph
> is not. I might want to create a glyph, cache it somewhere, and then use
> the same glyph to create bitmaps, outlines etc. with various parameters such
> as resolution etc. for the various drawing contexts (devices) I want to render
> the glyph to. It's simply two different animals which have as little to do 
> with
> each other as characters and glyphs. The only difference is that a glyph 
> *knows*
> how to create an outline or a raster from it (given the necessary parameters).
> That's why I see a Glyph mainly as a factory for Outline and Bitmap.
>
I now see your point of view very clearly !! However, what you're asking for is
simply not practical. :-(

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

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

> > anything else but the automatic deallocation issue. Sure, the latter is
> > solved then, but at the expense of a convenient C API.
> 
> I don't understand why you find the coupling of outline to the Glyph 
> convenient.
> It is against basic OO principles which try to decouple concepts as much as 
> possible.
>
don't take me wrong, but I believe that you're applying OO principles to the 
wrong
problem space..

> > It just occurred to me that the face->size field suffers the same problems
> > as face->glyph :-(.
> 
> 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.

The visible part of a FT_Size object is really minor compared to the control 
data.

> > Not sure if David likes us redesigning the entire API...
> 
> Right. I hope all my criticism is taken the way I intended it: constructive.
> 
I take them this way, but we have to agree on a few basic points..
It seems that the documentation doesn't clearly states that a FT_Size and
a FT_GlyphSlot are not atomic objects..

- David


> Best regards,   Stefan
> _______________________________________________________
> 
> Stefan Seefeld
> Departement de Physique
> Universite de Montreal
> email: address@hidden
> 
> _______________________________________________________
> 
>       ...ich hab' noch einen Koffer in Berlin...