Re: some more issues with the new API

[Just van Rossum]

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 description of the 'FT_Get_Glyph_Bitmap' function implies the latter.

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.

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.

Also, I don't quite understand your argument why a glyph shouldn't contain
a reference to an outline (or embedded bitmap). The thread-safety argument
doesn't fly here -- not that you brought it up, but I can't think of
anything else but the automatic deallocation issue. Sure, the latter is
solved then, but at the expense of a convenient C API.

It just occurred to me that the face->size field suffers the same problems
as face->glyph :-(.

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

Just