Re: Xft and Xrender support for GTK+ 1.2.8

["Bryan O'Sullivan" <bos serpentine com>]

o> Well, I'd be happy to see such a patch exist, though I think there
o> are some significant challenges that will probably keep it from
o> being incorporated into an official GTK+ release

o>  - Xft is still in flux.
o>  - Internationalization is a large amount of work (close to impossible)
o>    because GTK+-1.2 uses Xlib's fontset/output-method mechanism.
o>  - GTK+-1.2 programs are closely tied to the X font model - there
o>    is no abstraction layer between X fonts and GTK+ fonts.
 
I can see the first one making sense, but I am not so clear on why the
other two are necessarily problems.  Xft seems to have roughly the
same i18n support as GTK+ 1.2 requires, so it should be possible to at
least get to the same level there.  The latter seems to be more of an
issue, but I've found that Havoc's suggested workaround of loading a
core X font when I load an Xft font works well in practice.

b> [...] the work I understand Owen Taylor is doing on Pango for some
b> distant release.
o> ^^^^^^^

o> Hopefully not _too_ distant.

:-)

o> You'll need to handle clipping; you'll need to store the clip
o> Region with the GdkGC and set the clip on each XftDraw before each
o> call to draw a string.

Yes, thanks for pointing this out.

o> You really don't want to call XQueryColor for each draw-string
o> request; that's a round-trip to the server.

I've been aware of this, but thus far, it falls into the category of
"performance optimisation for when everything else works".

o> You can probably steal the implementation of
o> gdk_colormap_query_color() from the GTK+-1.3 sources - it avoids
o> calling XQueryColor() in all the common cases.

Thanks for the pointer.

o> But, I think the hard part is how you are going to handle naming -
o> fonts in GTK+-1.2 are identified by XLFDs, and if you expect to
o> work with any existing GTK+ programs, you'll have to do that.

Yes.  The scheme I'm currently using (not the one in the patch of a
few days ago) is as follows: I use XftFontOpenXlfd to open an Xft font
using the regular core name.  If this succeeds, all is peachy, and I
can use Xft calls (e.g. XftDrawString8) to render strings.  Otherwise,
if a core font is found, I fall back to using core X font rendering
calls (e.g. XDrawString and friends).

Since I keep my X and Xft font paths in sync, this works well in
practice.  In fact, with a newer set of changes than those on my web
site, I've been able to run stuff like Galeon and Evolution with few
problems.  Many fonts don't get anti-aliased, but this is at least
partly because of hard-coded references to non-scaled fonts.

I've been surprised to find that basically all GNOME and GTK+
applications have references to the Helvetica font hardcoded in.
Since the regular Adobe Helvetica font that comes with X isn't scaled,
this makes testing with, say, Monotype Arial instead a pain.

It's also confusing that Xft and core X don't use the same terminology
for things like rendering extents.  What core X thinks of as a glyph's
right bearing is just "y" to Xft.  Also, there's no Xft counterpart to
XTextWidth, which had me confused for a while (summary: the width of a
text extent is not the same kind of number as the value returned by
XTextWidth).

For the newest patch, with a few better screenshots:

http://www.speakeasy.org/~bos

	<b