Re: Xft and Xrender support for GTK+ 1.2.8

[Owen Taylor <otaylor redhat com>]

"Bryan O'Sullivan" <bos serpentine com> writes:

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

See my other post. Actually, Xlib has extensive internationlization
support that GTK+-1.2 relies on in a pretty deep way, though that
may not be evident from a casual inspection of the code.

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

Yes, if you are willing to make this compromise, then font naming
probably will work OK, except for font sets and internationalization.
 
> 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.

Well, you should be able make appropriate aliases in your .XftConfig...

Regards,
                                        Owen