Werner LEMBERG wrote:
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.
My sincere thanks for taking the time to look at it, and also for confirming that the problem is real (As opposed to me just misunderstanding/overlooking something!)
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.
No comment. In all honesty, I have no clear idea/plan how you'd like to do this, and I'll leave it up to you (And/Or the FT team) to address. As long as I can access my fonts via some supported technique, I'll be happy! [ Hopefully not requiring a radical rewrite though, if possible! ;) ] Actually, given that I'm probably a rare user (Having a custom font format), I'd even be open to any sort of hybrid solution which might be easier for you. Admittedly, exposing any sort of 'partially internal' stuff could put you back into the situation you worked so hard to get out of, so you might not want to go there. I'd just hate to see you spending a lot of time on redesigning/exposing something that very few users need. Basically, if I can: - Install a stock version of FT (ie: No customization) - Build our code against it (ie: No hacks, copies of header files) I'd be happy. ABI compatibility between versions is probably not much of a concern for us on Windows. Since there's no preinstalled version of FT on Windows, and we'd probably just build+ship our executables with whatever version of FT we need/choose. Building+Deploying on Linux would obviously be trickier though, since FT is a 'system' library and not under our control. We could probably impose some restrictions between build and deployment distributions though in this case.
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.
Ya, for the time being, I had already realized I was going to have to do this. Even if 2.3.7 has your proposed changes, I don't want to delay our FT upgrade until then. FT is used by so many other tools (eg: Cairo) that we simply *must* upgrade, due to conflicting dependencies. I'll classify this as a 'duct-tape' solution - Good enough for now! ;) Thanks again! Ian _______________________________________________ Freetype-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/freetype-devel
