Hello Ian, sorry for not answering this earlier, I'm just too busy.
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. the "internal" stuff has always been designed to be for internal use only. unfortunately, as they leaked to installable devel packages everywhere, some developers started using them directly to access certain features (sometimes, even when there were decent alternatives through the public API). this caused no end of chaos to users and packagers when we released new versions of the libraries, since they sometimes broke various libraries or programs (but not all of them) in subtle ways. that's why the internal stuff is not exposed anymore. we've gone to great lengths to ensure some sort of binary compatibility before closing these sources to client libraries and programs (in order to avoid breaking stuff again). the fact that we want to avoid breaking "rogue clients" also explains the comments in some of the internal structure definitions regarding the addition of new fields to structures. however, this is only a transitional thing since there are certain things we'd probably like to do internally to clean up some of the things done by the font engine. your code definitely qualifies as a "rogue client" since it relies on internals, so we do not guarantee that it will work in the future. the font driver interface is so fundamental to the engine's operation that I don't think we should expose it. if there is a specific feature that you implemented through this interface, we recommend that you file a feature request for it and we'll see what we can do to add a corresponding public API to support it. I hope this clarifies the situation and that we'll be able to find a way to help you in a manageable way. regards, - David 2008/6/18 Ian Britten <[EMAIL PROTECTED]>: > Hi all (Mostly Werner though, I suspect...), > Have you had a chance to look at that Driver sample I posted last > week, and if yes, have you had any thoughts about how you might > officially support external drivers in the longer term? > > At this point, I'm largely done porting our code (to FT 2.3.5), > and am looking to commit my changes for our other developers to > use. Unfortunately, without those couple of FT_INTERNAL header > files, no one will be able to compile our code. As I'm sure you > can appreciate, I'm loath to simply 'sit' on these changes until > autumn (Your proposed 2.3.7 release timeframe). > > Assuming that some sort of proper fix will be in v2.3.7, I'd like > to find a short-term hack/patch that will allow us to proceed, > but in a way that is compatible with whatever the final changes > will be. > > For example, one approach might be to add the relevant FT header > files to our code repository (Unmodified), restict our build to > *only* 2.3.5, and then do a proper fix once 2.3.7 is released. > Does anyone see any [Technical? Legal? Moral?] problems with > something like this? > > Or, does anyone have any other suggestions/approaches? > > Many thanks for any info! (And keep up the great work!) > Ian > > > _______________________________________________ > Freetype-devel mailing list > [email protected] > http://lists.nongnu.org/mailman/listinfo/freetype-devel >
_______________________________________________ Freetype-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/freetype-devel
