Re: some more issues with the new API

[Stefan Seefeld]

Just van Rossum wrote:
> 
> At 4:13 PM -0500 15-03-2000, Stefan Seefeld wrote:
> >> While further thinking about decoupling FT_Glyph(Slot) from FT_Face, I got
> >> stuck at the FT_Glyph->outline field. This is owned by the glyph, but what
> >> should a wrapper do? Keep a reference to the glyph so the glyph doesn't get
> >> destroyed before the outline does? What other options are there?
> >
> >Hmm, that depends on what a glyph really is. Is it just the data so dependent
> >on some discriminator the structure contains an outline or a bitmap,
> 
> Sorry, my brain raises a syntax error on that sentence... (In other words:
> what do you mean exactly?)
> 
> >or is it a
> >real object which can *create* an outline or a bitmap if asked to ?

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.

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 ? 

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

> I'm not sure if you're on the right track: the C API you conclude with is
> very verbose and is not very practical.

Why not ?

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

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

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

> Not sure if David likes us redesigning the entire API...

Right. I hope all my criticism is taken the way I intended it: constructive.

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

_______________________________________________________

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