Re: [ft-devel] Regarding the 2.1.10 release

[Lars Knoll]

Hi David,

On Wednesday 23 March 2005 18:18, Turner, David wrote:
> > 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.

As I said, it's no problem for me to do the work, if I have some directions.

> 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 :-)

True :)

> > 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.

I know you're not, but as there unfortunately are libs out there using it's 
internals (I know I'm guilty as well...), I thought it might be a good idea, 
so you can still run an older version of Qt/Gtk after you upgraded freetype.

> 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.

I know that just too well and I really understand that you want to get rid of 
them. Qt has a "private" subdirectory in it's installed include files as 
well, and that was one of the things we changed for Qt 4. 

> 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.

You misunderstood me there. I completely agree with you that private headers 
should not be exposed and installed, and I can understand that you want to 
get rid of them.

> > 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.

Ok, I'm perfectly fine with this :)

> 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.

Great. 

> > 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

Yes, I see your point there. I don't mind it staying outside. Unifying the 
different branches of the open type code is something I should probably 
rather try to achieve with Owen at some point.

Best regards,
Lars