Re: PangoXft and PangoFT2 patch from hell

[Owen Taylor <otaylor redhat com>]

Sven Neumann <sven gimp org> writes:

> Hi,
> 
> Alex Larsson <alexl redhat com> writes:
> 
> > Here is a patch that adds some generic font aliasing support to Pango. It 
> > also has code for the Xft backend to support font-aliases from the Xft 
> > config files. It also contains a rewrite of the pangoft2 backend to use 
> > the same config file format as the Xft backend so that you will always get 
> > the same fonts in Xft and FT2. The PangoFT2 internal API is also 
> > simplified because it doesn't have to do fontsets.
> > 
> > The minixft.tar.gz tarball must be unpacked in $SRC/pango/mini-xft, and 
> > contains a copy of Xft without X dependencies.
> 
> I don't see the benefits of this approach and don't like the idea of 
> wrapping Pango closely around Xft. I also don't see how the Xft config
> files are better than the FT2 alias files we have now. Because of this 
> I fear that MiniXft adds (unneeded?) overhead and won't help to make
> GTK+-FB or GTK+-DirectFB a lightweight library for embedded devices.
> But then I guess you have good reasons for making this change. It would 
> probably help if you could explain them further. 

 - MiniXft is tiny
 - THe FT2 config file format is by far the most common FAQ
   for people trying to get GNOME-2.0 running. If you have 
   your fonts configured for Xft, you should not have to
   configure them again for libgnomecanvas and the GIMP.
 - Multiple font configuration systems are _evil_; they are the
   bane of any system integrators life.
 - Xft is being split into two pieces, one X dependent, one not.
   The goal is to make the non-X piece useable for anybody that
   needs a font configuration system. Getting this adopted
   is really very important for the success of free software.

On systems using Linux, MiniXft is clearly the right way to go.
On Win32 systems, we might want to eventually investigate some
sort of mechanism where the FT2 library could share the same
font lookup system as the Win32 backend. That's too ambitious
for now.

Regards,
                                        Owen