Re: FT2 design question

[David Turner]

Hi Just,

Just van Rossum a écrit :
> 
> I'm in the process of designing a clean Python interface to the core FT2
> API, and am wondering about the following.
> 
Waoaw !! Already, things are getting pretty fast. I must warn you of a
few things that will likely change in the near future (see the end of
this email).

> If I understand it correctly, the ability to have multiple instances of
> FT_Library is mainly meant for DLL use, so various clients have completely
> independant contexts. Are there other reasons?
> 
The purpose is simply to make the library re-entrant, with no static
variables, no other hidden reasons (for now ;-) !!)

> The reason I ask is that I consider creating *one* global FT_Library
> instance in the Python wrapper module: from a Python module's perspective,
> it doesn't seem to make sense to be able to have multiple instances of the
> FT_Library object.
>
I completely agree.

> Doing this means basically that I turn all FT_Library methods into
> functions, where the library instance gets passed implicitly.
> FT_Init_Freetype() would then be called automatically the first time the
> module gets imported ("import freetype"), and would not be accessible
> explicitly from Python. I tend to think this simplifies the Python version
> of the API without taking away any flexibility.
> 
> Another reason why I think this would be the way to do it, is that certain
> functions which are now technically methods of the library object (but only
> because the use the library's memory manager, like FT_New_Outline and
> FT_Done_Outline) would look like global functions from within Python, as
> they should. Not only is this slightly easier to use, it is definitely
> easier to implement: it makes automatic finalizing the objects (crucial in
> Python!) much more straightforward to get right.
> 
> Separate Python processes using freetype would still (and automatically!)
> get their own instance of the library object, so I don't think any harm is
> done in making it implicit.
> 
> Any compelling reasons not to do it this way?
> 
Frankly, I believe that you just got it right :-) It's precisely
the way I would have myself designed it. Go for it.

But before that, here is a list of things that might change soon in the
high-level API :

  - FT_Outline :  the various flags will be joined into a single unsigned
                  int (or long) instead of using chars to store boolean
                  values. This will also allow the introduction of new
                  flags needed by the auto-hinter I've started working
                  on (mainly flags indicating the conventions used to
                  fill outlines). Actually, I can change this this
                  afternoon if you like.. (the sooner, the better).

  - FT_Raster :   I am still experimenting with "YAAAR" (yet another another
                  anti-aliasing raster). This latest incarnation has very
                  interesting properties, one of them is being able to
                  "directly" render anti-aliased glyphs into any kind of
                  target pixmaps (no need to use an intermediate 8-bit one).

                  I'd like to be able to do the same thing with the monochrome
                  raster, but I'm mostly working on it..

                  This means that you should probably expect a change in the
                  raster interface (note that it shouldn't really make it to
                  a Python interface anyway :-), and probably in
                  FT_Get_Glyph_Bitmap.

  - Auto-Hinter:  I've started thinking hard about a auto-hinting module, and
                  will be able to revel more details on it in a few days. I
                  don't expect it to change the high-level interface (except
                  maybe one or two more FT_LOAD_xxxx flags) but we cannot be
                  too sure. Note that it will certainly change the fields of
                  "FT_FaceRec" a little.

  - Multiple masters support:
                  I'm studying how to add multiple master support
                  to the Type 1 driver, as well as defining a high-level
                  interface for it. This may change the layout of
                  "FT_FaceRec" a bit, and most definitely "T1_FaceRec"
                  (but I expect you not to make those low-level structures
                   visible in Python right now..).

That's it for now. If there are other things that people would like to see in
the high-level interface, they're welcome to comment on it in the list..

- David

> Thanks,
> 
> Just