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 <[EMAIL PROTECTED]>: > > > > 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 >
_______________________________________________ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel
