Re: GTK+-2.x planning



Around 22 o'clock on Mar 12, Havoc Pennington wrote:

> You just gave the reason why it isn't there though - it's broken for
> i18n, and lazy developers will use it for things like XChat for no
> good reason. ;-) XChat could easily use PangoLayout instead of being
> broken, I don't see how it could possibly be that hard.

Translating an application to Pango is a lot of work; it requires changing 
how text is managed so that updates are propagated into the layout library 
rather than simply being reflected by the rendering operations.  Pango 
also has some significant performance implications when used in 
non-optimal ways, the initial xchat port was apparently unusably slow.

Xft provides trivial "i18n" for languages which have a 1<->1 mapping from 
characters to glyphs; that covers a significant fraction of the worlds 
languages making it difficult to sell Pango to developers writing code for 
only a few locales.

While I'd like to see everyone writing to the Pango API, it's also
impossible to enforce it.  The current mechanism just makes it harder to
integrate font selection among the various portions of the application, as 
well as reducing portability among various Gtk+ implementations.

> Can people use Xft with "old" (not really very old) X servers that
> lack RENDER? If not, I don't think we can drop core X fonts yet.

Yes.  Xft2 supports all X servers and even does AA/sub-pixel text on all
TrueColor visuals.

> We'd also need it to be simple to download and install Xft on a system
> without having to get all of XFree, probably.

That's what Mozilla will be doing for it's Xft code for the time being.

I have been asked by more than one group to make Xft/Fontconfig releases 
at a faster rate than the core XFree86 release schedule.  I don't see any 
problem with that.

> But yeah I'd love to go Xft-only as soon as it's remotely feasible.

I think it's possible right now; I run four separate Xft-only toolkits on 
my machine along with an Xft-only Mozilla.  The Xft2 port for Pango really 
cleaned up some pretty nasty code inside the current implementation 
(miniXft as well as Unicode coverage of fonts).  This also unifies font 
selection and configuration under the Fontconfig library making fonts 
portable from display to printer.

While I don't believe we need to continue supporting bitmap fonts, 
FreeType and Xft do support PCF fonts.  FreeType needs to add the minor 
support needed to handle compressed PCF files and Fontconfig needs to add 
support for non-Unicode (or Latin-1) fonts.  That will be easy as XFree86 
already has transcoding tables for all of the font encodings we ship, it's 
just a matter of loading the transcoding table and mapping character codes 
around.

Keith Packard        XFree86 Core Team        Compaq Cambridge Research Lab





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]