Re: some more issues with the new API

[Just van Rossum]

At 9:23 PM -0500 15-03-2000, Stefan Seefeld wrote:
>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.

Right. I think we are partly discussing direct attribute access -- as in
glyph->outline -- vs. accessor methods -- as in glyph->getOutline() -- and
partly discussing ownership. Maybe we should try and separate the two. I
don't have a strong opinion about accessor vs. direct access, both would be
fine with me, but for the C API direct access is more convenient. FT2
actually *prefers* direct access, compared to FT1, and, from a C point of
view, that seems like a good thing.

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

Convenience.

As to what a glyph *is*: in my view a glyph is some 'drawable' plus
metrics. What the drawable is might be an implementation detail, so *maybe*
it's an idea to try and degrade status the outline and bitmap fields of the
glyph to "private"? That would mean all outline methods should become
methods of the glyph object:

FT_Glyph_Get_Bitmap(); // hey, this one doesn't change! ;-)
FT_Glyph_Translate();
FT_Glyph_Transform();
FT_Glyph_Hint();
FT_Glyph_Decompose_Outline();

and:

FT_Glyph_GetAdvanceWidth();
--or--
glyph->advanceWidth;

>> FT_Get_Glyph_Bitmap() doesn't create a bitmap: the FT_Bitmap needs to be
[ ... ]
>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.

Yes. Or render it into the user provided one, it it's an outline glyph.

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

Because it's too verbose? ;-)

>> 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'm not sure about that: if you ask a face for a glyph at a specific size &
resolution, that glyph is device dependent. But maybe I'm already thinking
too much in terms of the glyph being an atomic object.

>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 see what you mean. Maybe you're right. I'm confused, since it is not
entirely clear what semantics David intended. I'm trying to come up with a
minimal proposal that makes FT2 more OO, while changing as little as
possible... But it appears the problems are much deeper, and possibly
unsolvable without major changes. But the bigger the change, the less
likely it is for David to ever accept it.

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

Principles are meant to be broken...

Seriously: what do you think about my idea to turn the glyph object into an
atomic object?

>> Not sure if David likes us redesigning the entire API...
>
>Right. I hope all my criticism is taken the way I intended it: constructive.

Same here.

Just