On Thu, 2006-02-16 at 07:08, david turner wrote: > I still don't understand why you absolutely want the ability to > dynamically peek into the > internals of the libfreetype installed on the system, especially since > it will not have the > bytecode interpreter on most distros anyway... I want FontForge to run on any system whether it has freetype installed or not.
If freetype is not installed then I use ff's built in (poor) rasterizer. I want FontForge to run on any system with freetype whether it has the bytecode interpreter enabled or not. If freetype has no bytecode interpreter then fontforge doesn't do truetype debugging. I don't want to have to provide three different fontforge builds for each system. I don't want fontforge to crash on startup if there is the "wrong" kind of freetype on the system. So I do dynamic linking. That way I can customize fontforge's behavior depending on what is available. I want one executable that can adapt itself to all situations and do the best it can with what is available. I want to impose as few required dependencies on the user as possible. Nobody else seems to think this way, but to me it's the obvious solution to a problem. Take advantage of what's there but require as little as possible. I need TT_RunIns because I install a DebugHook, and (as I understand it) a DebugHook is pretty useless if it doesn't call TT_RunIns. I need the internal headers so I can display the state of the interpreter to the user. ============================ I'm not entirely sure what improvements I'd see if I extracted the truetype code into a library all by itself. It would be smaller, yes, and I suppose easier to distribute with fontforge, but it would still become divorced from the true freetype code and subject to divergence (just as pango's incorporation of some of the old ft1 code gained bug fixes in some places but not others). And I don't just use the truetype code in freetype. I am also a normal freetype user and rasterize glyphs in the normal way, so I need the full library for some things. Having my own private copy for tt debugging while using the installed freetype for rasterization sounds like exactly the can of worms you are seeking to avoid with the new version of the library. I would worry about shipping a fontforge with a statically linked freetype (or part of freetype) with the bytecode interpreter enabled for patent reasons. I would worry equally about shipping a plug-in with the bytecode interpreter enabled. Isn't that exactly what a library is? And hasn't Apple said that's a bad idea? For users to access the debugger I'd still require them to do their own builds and change the default configuration setting of my embedded freetype. To me, including the freetype sources with mine own sounds a) unethical b) not something that solves any of the problems I worry about. Your concern is (I think) that the internals of freetype will change and fontforge will break. That's ok. I'll fix it and there will be a version of ff which works with old freetypes and one that works with new freetypes. This happens occasionally. The author of autotrace changed the command line arguments for autotrace some time ago. Old fontforges only work with old autotraces. New fontforges only work with new autotraces. After someone reported that autotrace had changed its arguments and I posted a build that worked with the new version (and documented the fact) no one complained. It's essentially the same problem, and not one that worries me. Now, if ff ever were to become a commercial product that would be completely different. Then I'd have to insure that the install process installed everything it could possibly need: all image libraries, libxml, libfreetype (with bytecode), etc.. I'd have to talk to you and Apple about licensing. That's a lot of hassle and probably some expense, but it isn't worth it for something I'm giving away. That's not what I find fun. So I'm happy with things as they are, just so long you don't remove the entry point I need... And Werner says you haven't. You can change the internals and I can work around that, but if you remove the entry point I'm stuck. _______________________________________________ Freetype-devel mailing list Freetype-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/freetype-devel