Re: Say goodbye to core X fonts

[Owen Taylor <otaylor redhat com>]

On Wed, 2003-04-16 at 05:35, Arnaud Charlet wrote:
> I have a question about not having any X back end anymore.
> 
> This is a bug issue for us, because we have to support Gtk 2 based applications
> on old systems (e.g. Solaris 2.6, IRIX, AiX, Tru64, HP-UX) where it may not be
> practical to install a prebuilt Xft2 library.

I don't see why Xft2 is much worse than the other dependencies of
GTK+. The minimum requirements of GTK+-2.2 on a legacy system are:
 
 GNU make/libiconv/libintl/libpng/libjpeg/libtiff

This just adds

 expat/FreeType/fontconfig/libXrender/Xft
 
And in fact, even with 2.2, you'd be really advised to install
expant/FreeType/fontconfig, since many GTK+-2.0 apps (like the
GIMP) require the FT2 backend explicitely.

Is going from 6 dependencies to 11 something I'm happy about? 
No. But it seems to me to be a matter of degree rather than 
kind.

> Another issue with Xft2 is that it makes is even harder to make stand alone
> binary distributions (ready to be used, and installed at any location) of
> Gtk 2 applications (again, not everyone is running the latest version of linux).

I don't think a "standalone" binary of a GTK+ has been reasonable
since 2.0 came out. While with --with-include-* it is *possible*
to make a totally statically linked copy of a GTK+, it takes
an expert and is 200% harder than simply compiling GTK+ and
all its dependencies.

Plus, a "standalone" GTK+ app binary is likely to violate the LGPL.

Maybe we need to come up with some standard way of installing
the 4 GTK+ libraries and 10 dependency libraries in a "legacy" system
in a self-contained way.

E.g., you run your program as:

 /opt/gtk2.2/bin/gtkwrap my-binary

And /opt/gtk2.2/bin/gtkwrap sets all the necessary environment variables
to point 'my-binary' at /opt/gtk2.2.

> Even under linux, most deployed linux systems today have a broken Xft
> library.

A lot of linux systems aren't going to have Xft2, yes, if that's
what you mean by "broken".

> I am not saying removing the core X back end is a bad thing per se, I
> understand all the nice advantages of using Xft.
> 
> So my question for the time being I guess is: "how long will new versions
> of Gtk+ stay compatible with pango 1.2, so that a fallback at least exists
> for those who can't switch to pango 1.4 ?"

It's really a question of whether we'll have the time to add new useful
API features to Pango in this release; there are a couple of useful
proposed features that are pretty small:
 
 - List the available sizes for a non-scalable font
 - Filter listed fonts to only "fixed pitch" families.

If we don't get around to these features, then we might as well keep
pango-1.2 (and even pango-1.0) compatibility, since the pango-x specific
rendering code in GTK+ is tiny, but if we do add features, then we have
to require a new version of Pango.

Regards,
                                            Owen