Re: some more issues with the new API

[David Turner]

Hi,

> 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();
> 
Well, the question is really to know how we define a "glyph" for a high-level
C++ or Python wrapper. I don't think it needs to be defined in FreeType 2, but
I retain the idea of:

   Glyph/            the root glyph class, contains metrics, no image, 
device-dependent.
      BitmapGlyph/   -- as it name suggests, a bitmapped glyph 
      OutlineGlyph/  -- as it name suggests, an outline glyph

  face.load_index( index, flags ) would load a glyph image into the glyph slot
  according to the "flags". Note that this image is only one view for given 
glyph
  index. Similarly, face.load_char( charcode, flags ) would load a glyph image
  by character code..

  face.get_glyph() would create a new BitmapGlyph object and copy/render the 
glyph
  slot's image into it.

  face.get_glyph_outline() would return an OutlineGlyph if there is one in the
  glyph slot, 0 otherwise

  face.get_glyph_format() would return the glyph slot's image format..

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

> >> 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.
> 
No problem :-)

- David