Re: FT2 design question

[Just van Rossum]

Hi David,

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

I was expecting that... No problem. I hope to create the wrapper
semi-automatically, and even if hand edits will be neccesary I still don't
mind. I think it's a good excercize for FT to have an external interface in
an early stage. The more access, the more bugs get discovered and solved...

[ ...zapp... ]
>Frankly, I believe that you just got it right :-) It's precisely
>the way I would have myself designed it. Go for it.

Excellent.

>But before that, here is a list of things that might change soon in the
>high-level API :
>
>  - FT_Outline :
>[...] Actually, I can change this this
>                  afternoon if you like.. (the sooner, the better).

Oops, the afternoon is over... Seriously: I have no hurry, and don't mind
later changes. I do have a suggestion for some additional FT_Outline
methods, though, which I might implement, and submit it if you like them:

  FT_Error FT_Outline_AppendPoint(
                FT_Outline* outline,
                FT_Vector* point,
                FT_Boolean onCurve,
                FT_Boolean isCubic);

and possibly also these:

  FT_Outline_MoveTo(outline, to)
  FT_Outline_LineTo(outline, to)
  FT_Outline_ConicTo(outline, control, to)
  FT_Outline_CubicTo(outline, control1, control2, to)

[Hm, if you'd change the FT_Outline_XXX_Func callback arguments to
  typedef int  (*FT_Outline_XXX_Func)( void* user, ...rest of args... );
you'd have a more symmetrical interface. Makes more sense to my
anyway, since these callbacks *can* be viewed as methods of the void*
user object ;-]

Another suggestion: the current names of FT methods seem somewhat
inconsistent. I would suggest to *always* use

  FT_<objectname>_<methodname>

So FT_Decompose_Outline becomes FT_Outline_Decompose. FT_Face methods may
be a special case: they seem to be the top level objects (ignoring the
library ;-). The advantage of such a scheme is that real OO wrappers may be
able to use cleaner names according to simple rules. I'm also considering
dropping the FT_ prefix, which is unneccesary in Python. An example FT
program might look like:

import freetype
face = freetype.New_Face("Arial.ttf", 0)
face.Load_Char(0x41, 0)
outline = face.glyph.outline
etc.

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

Cool.

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

Heh... I already *have* an interface to the (standalone) raster ;-)

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

Very exciting! Will you build it in such a way so that it may be used
separately? I'm asking since I'm working on a new version of RoboFog (our
Python enhanced font editor) and would love to use your code to create
hints for T1/T2 outlines. A large part of RoboFog MkII (as we call it) will
be open source (in fact, that's what my FontTools package really is...),
and I hope to create an API to add plug-in autohinters.

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

You are aware of the fact that MM is basically dead? Adobe announced that
they will continue to support it in apps/tools that support it now, but
a) they won't release new MM fonts
b) they've dropped MM from the OT spec

As cool as MM is from a conceptual point of view, it's a nightmare to
support it...

>                  (but I expect you not to make those low-level structures
>                   visible in Python right now..).

Not sure yet... Many FT_FaceRec fields are kindof important, so I'll try to
put those in.

Just