Re: [ft-devel] On the impact of installing the next FreeType release on a typical Unix distribution

[George Williams]

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.