[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: FT2 design question
From: |
David Turner |
Subject: |
Re: FT2 design question |
Date: |
Mon, 28 Feb 2000 12:56:25 +0100 |
> >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
- Re: FT2 design question, (continued)
- Re: FT2 design question, Werner LEMBERG, 2000/02/26
- Re: FT2 design question, Just van Rossum, 2000/02/26
- Re: FT2 design question, Pavel Kankovsky, 2000/02/27
- Re: FT2 design question, Stefan Seefeld, 2000/02/28
- Re: FT2 design question, Werner LEMBERG, 2000/02/29
- Re: FT2 design question, Stefan Seefeld, 2000/02/29
- Re: FT2 design question, Werner LEMBERG, 2000/02/29
- Re: FT2 design question, David Turner, 2000/02/28
- Re: FT2 design question, Stefan Seefeld, 2000/02/28
- Re: FT2 design question, Just van Rossum, 2000/02/25
- Re: FT2 design question,
David Turner <=
- Re: FT2 design question, Werner LEMBERG, 2000/02/28
- Re: FT2 design question, Just van Rossum, 2000/02/29
- Re: FT2 design question, Werner LEMBERG, 2000/02/29
- Re: FT2 design question, Just van Rossum, 2000/02/29
- Re: FT2 design question, Just van Rossum, 2000/02/28
- Re: FT2 design question, Just van Rossum, 2000/02/28