Re: GDK_FONT_XFTFONT

[Owen Taylor <otaylor redhat com>]

Keith Packard <keithp keithp com> writes:

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

It's reasonably easy on X, but we also have Win32 to worry about.
Making emulation of XLFD's something we have to support on every
platform, and something that we have to support going forward
is not something I want to do.

Plus, the handle of encoding for gdk_draw_string() and friends
is really screwy for historical reasons.

(It's either encoding of the local, 8 bit glyph indices, or
16 bit glyph indices depending on the type of font.)
 
> >  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.

The terminal widget part is in the 'libzvt' package.

The code is already split out to work with a couple of different
types of fonts; it either renders with XDrawString or XmbDrawString
depending on whether it has a font or a fontset. Making it support
Xft as well shouldn't be hard.

(Except that the character width handling and character storage
in libzvt needs much work.)

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

It's not clear exactly what the performance issues were, it sounded
when I talked to him about it over the weekend that he was perhaps
doing things in an inefficient way. (Emulating DrawString rather
than passing entire paragraphs to Pango.)

Pango speed isn't wonderful, but it should be perfectly fine for IRC;
the nice thing about IRC is that you start with an empty buffer,
so you don't have to lay out 1000's of lines at the beginning
as you do for a text widget. (We implemented incremental reflow
in GtkTextView for this reason... it does about 10000 lines
per second.)

And I'd rather work on optimizing Pango than providing alternatives
because it isn't fast enough.

(My big performance problem with Xft right now is computing
coverage information, which either will be fixed with some
more code on our end or when we switch to fontconfig.)
 
> He's definately not planning on trying Pango again any time soon.  

He didn't sound that hard-line on me, though he wasn't very
happy with the idea of having to rewrite the display widget.
I said I'd take a look at doing the Pango conversion after we got 
GTK+-2.0.0 out.

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

People use IRC with non-ASCII encodings - ISO-8859-1 in Europe,
one of the Japanese encodings in Japan. I suspect UTF-8
could be used as well, and if not, you want i18n support to
support this use of legacy encodings.
 
> > 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.
 
You may well be well right that we should have worked on making
GdkFont still work; it's certainly a bit of a API hole that there
isn't a conventional character-by-character text drawing API
available.

(I have some ideas for extending Pango to allow shaping
engines to provided simple Unicode => glyph mappings to
support this.)

But considering that we are releasing this weekend, it's not something
we can go back and revisit at this point.

(While adding a 3rd type of font may seem like a small API compatible, 
change, it's actually something that can easily crash applications
that aren't expecting it.)

Regards,
                                        Owen