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