freetype-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ft-devel] Roadmap for supporting external Drivers?


From: David Turner
Subject: Re: [ft-devel] Roadmap for supporting external Drivers?
Date: Thu, 26 Jun 2008 09:10:20 +0200

I don't think we want to publicly export the FT_Driver internals at all. doing so would require just too much work
for so little benefits. on the other hand, we can foresee the definition of a public FT_UserFontDriver structure
that could be filled up by client libraries and apps to implement some level of user-level font support.

this structure would be much simpler than FT_Driver and only expose a minimal number of features.
we need to find a good balance between what most user-font providers need and what we can support..
if you want a full blown font driver; it should be part of FreeType, or you should deal with the changes in
internals, period.

which is why I was asking Ian what kind of "features" he wants to see supported.
"exposing the internal font driver" is a no-go, but something like
"overriding the shapes of certain characters" could make it.

so again, what are you using this custom font driver for precisely ?

2008/6/25 Werner LEMBERG <address@hidden>:

> > the answer is that there is absolutely no roadmap to expose the
> > font driver interface publicly. the fact that the "internal"
> > headers were distributed in previous releases of the library was a
> > distribution error on our part.
>
> I must confess though that I got the impression from recent
> discussions that writing a driver was something that was intended to
> be supported, which is why I continued trying to simply 'port' our
> current code.  If you're saying that isn't the case, then I fear
> that I may be 'stuck between a rock and a hard place'.  Suddenly not
> being able to access our own fonts any more would leave our
> customers quite unhappy.

I've played a bit around with your font driver skeleton.  And indeed,
as you've already pointed out, many internal structures (besides the
stuff in ftdriver.h) had to be exposed to the public, which is bad.  I
don't have the time (and, admittedly, the skills) to redesign the
driver interface so that dependencies on internal header files can be
avoided.

> Please let me know if you have any questions, or if there's anything
> I can do.

The excercise is clear: Redesign the API given in ftdriver.h so that
it can be lifted to the public level, relying only on opaque pointers
(cf. the FT_Xxx_Internal typedefs in freetype.h) if really necessary.
Such an API should be extensible so that new font driver capabilities
could be added -- something like `FT_Driver_Add_Function' comes to my
mind, but maybe other solutions are possible too.

Until this happens, you probably should simply continue to use the
internal header files in your project, tracking changes of its
contents as soon as new versions of the FreeType library appear.  This
is not as complicated as it may sound since changes are not too
frequent; George Williams, for example, does the same for FontForge,
providing a great interface for TrueType bytecode debugging.


   Werner


reply via email to

[Prev in Thread] Current Thread [Next in Thread]