RE: [ft-devel] Regarding the 2.1.10 release

[Turner, David]

Hello Lars,

> Please remember that these are not the only projects around. 
> At least Qt does also use the opentype code that unfortunately relies on 
> internal freetype headers, but I'm sure there are some more projects out 
> there. 
> 

The Qt patch should be very similar to the Pango one, and I'll try to
provide that as well. For other projects, they will be provided as
needed, but I don't think many programs use the non-public API
anyway.

Note however that the recent changes are not related to the internal
stream handling functions, which means that they don't have an impact
on the Qt code you're speaking about.

> > - after completion of the patches, the real release will be
> >    made with FT_OPTIMIZE_MEMORY defined. Its configure script
> >    should try to detect unpatched versions of the offending
> >    libraries and produce HUGE WARNINGS when compiling FT2.
> >
> > - moreover, this new release will not install the FreeType
> >    internal header files in <prefix>/include/freetype2/internal
> >
> > - instead, it will install 'dummy' headers, which purpose
> >    will be to produce #errors at compilation time, in order
> >    to inform developers that they should upgrade the libraries
> >    they're trying to link with FT2... (again, trying to be
> >    descriptive)
> 
> Why install them at all then? If they are completely missing, 
> you'll get a compile error as well. The error will not be quite as 
> descriptive, but I  don't think that matters.
> 
I think it does matter. Pointing to an URL which gives a clear
description of the problem, as well as a list of available patches
for the offending libraries is going to help.

It will also reduce the panic messages on the mailing lists :-)


> The changes you're proposing are rather big, and break both 
> the API and the behaviour of freetype. Have you considered changing the 
> library version number for this release to 7, so old applications using 
> freetype < 2.1.10 can continue to work?
> 
First of all, this doesn't change the _public_ API one bit. 

This also doesn't change the library's behaviour except for the
'rogue' code mentionned.

It only concerns libraries that happen to use internal functions
of FT2 because their developers didn't realize that they should ask
for relevant additions to the public API instead. And it's not
like they've not been warned before.

Our mistake was to allow the installation of whatever is in
"include/freetype/internal" to the PREFIX directory in the
first place.

What you may not realize is that the FreeType internals have already
changed several times, sometimes creating problems (ask FontConfig),
sometimes not, depending on what has changed. I don't want to take
extra care when I'm maintaining the library and improving its internals,
just because some damn stupid lib, in one of its releases, was using
something it was not supposed to do.

I'm fed up with the situation, which doesn't mean that I want to
break binary compatibility for the sake of it. Which means that
incrementing the library number to 7 is _definitely_ a good idea.

You may think it's a bad idea, but I believe it will simplify the
life of many people once this big step has been achieved.


> Currently the open type code used by both Qt and pango 
> includes 4 internal 
> headers from freetype:
> 
> #include <freetype/internal/tterrors.h>
> #include <freetype/internal/ftstream.h>
> #include <freetype/internal/ftmemory.h>
> #include <freetype/internal/tttypes.h>
> 
> The main problem we will have is that we will have to support older 
> installations of freetype for a while, so we need a way to 
> make the open type code compile with both 2.1.x (<10) and 2.1.10, and we'd 
> need 
> some advice on how to replace the internal headers with public API. I'm 
> happy to do all that's required to make Qt work with the new freetype version 
> as long as I get some hints on how this should be done.
> 
I believe it is possible to modify the OpenType code (both in Pango and Qt)
to get rid of any internal dependencies. This will probably be performed by
a little bit of macro juggling and limited code duplication, but it's doable.

what it will allow however is the ability to run with any version of FT2
(old or new). That's what I'm targetting for the patches, but I don't know
if it will be possible for all libraries.

This is going to take some time, and I'll post my progress about it on this
mailing list, so that the proposed patches can be discussed. People will
still be able to install the 2.1.10rc1 if their distro is not too old
anyway.

> Another possibility I can see would be to move the open type 
> code back into freetype. It would require some work on the public API of the 
> open type module, but would finally unify the different versions of the 
> open type code floating around in different projects again.
> 
it we did this, you wouldn't be able to support older installations of the
library anyway. I also believe that something as complex as OpenType parsing
shouldn't be in the font library itself. But that's a different topic


Regards,

- David Turner
- The FreeType Project  (www.freetype.org)