Re: FT2 design question

[David Turner]

> >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 ;-]

But these methods are used to build outlines, aren't they ? This is something
that is more useful to a font builder than FreeType itself. However, feel
free to implement them in "src/base/ftoutln.c" if you want them, they
shouldn't hurt (please also define a configuration macro like
FT_CONFIG_OPTION_BUILD_OUTLINES to control their compilation. I'm an embedded
systems freak, and like the ability to choose which features I want when
building a library :-)

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

Yes, it's definitely worth it. I'll try to do this progressively this week.

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

Absolutely no problem here, au contraire...

> >  - 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.
> 
I can't really tell why, but the hinter will have an external API, and
will most probably have a 'standalone' version, just like the current
raster. But it's a bit too soon to discuss the topic :-)

> >  - 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...
> 
That's excellent news. I've never really understood the advantage of
multiple master fonts from a user pôint of view. Sure, they're great
to perform font-substitution in PDF files, but apart from that ?

> >                  (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.
> 
Sorry, I was just speaking about the T1_Face structure :-) All of 
FT_FaceRec is public and important :-)

- David

> Just