Around 10 o'clock on Feb 25, Owen Taylor wrote:

> What we decided for GTK+-2.0 is is that we would simply deprecate
> GdkFont and keep them working the same way, rather than trying to make
> them take advantage of any of the new features of GTK+-2.0.

But it's so easy to make GdkFont work, and porting applications to pango 
takes a lot of work.

>  gnome-terminal - it actually mostly access X11 fonts directly, probably
>    easiest to switch it over using Xft directly. Complex-text in
>    a terminal is a very different proposition than real complex-text
>    so Pango is a poor match here.

I haven't found the sources to gnome-terminal yet.  Unless it's bypassing 
gdk_font, this seems like the perfect candidate for a modified gdk_font 
that also can support Xft.  Until all X servers support Render, Xft will 
be somewhat slow for drawing a lot of text, and the terminal emulator is 
one application where text speed is important.

>  xchat - Main text widget hasn't been ported yet; needs a rewrite
>   to work in terms of Pango.

I asked the maintainer of xchat and he tried pango and gave up; it's too 
slow at this point.  It may be that my new version of the Pango Xft bits 
will resolve most of the performance issues (it draws more than one 
character at a time).

He's definately not planning on trying Pango again any time soon.  As the 
IRC protocol is essentially ASCII (with {}\ the "lower case" versions of 
[]/), there's no real reason to use Pango, the existing gdk_font object 
can display all of ascii quite easily.

> But the planned path is definitely to get rid of GdkFont rather than
> trying to fix it. 

Given that the "fix" requires so few lines of code, and given that at 
least gnome-terminal should probably use this interface to remain neutral 
in the core-vs-Xft font battle, I believe there is value in the modest 
change proposed.

Requiring everyone to immediately migrate to the "perfect" solution means 
that many apps will be left with inconsistent fonts as the authors may
have a different set of requirements than the library wants to impose.

Keith Packard        XFree86 Core Team        Compaq Cambridge Research Lab

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