Re: Xft and Xrender support for GTK+ 1.2.8

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

> Hello, world -
> I spent a few hours tonight hacking together preliminary support for
> Keith Packard's Xrender extension and Xft anti-aliased font code,
> which come with XFree 4.0.2.

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

 - Xft is still in flux.
 - Internationalization is a large amount of work (close to impossible)
   because GTK+-1.2 uses Xlib's fontset/output-method mechanism.
 - GTK+-1.2 programs are closely tied to the X font model - there
   is no abstraction layer between X fonts and GTK+ fonts.
Also, as Havoc said, other people have been working on this for a
while, so you should pool efforts.
> The code is grafted on top of GTK+ 1.2.8, since I wanted to see
> whether I could get something up and running with minimal effort,
> independent of the work I understand Owen Taylor is doing on Pango for
> some distant release.  Between midnight and 4am this morning, I got at

Hopefully not _too_ distant.

> least a few simple apps working.
> Prepatch and obligatory screenshot are at
> The prepatch has a number of shortcomings and bugs, some of which will
> be obvious to any reader, and others which will only be clear to Keith
> Packard, since I'm depending on the documentation and examples he
> dropped into XFree 4.0.2 :-)

Hmm, a few trivial notes:

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

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

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

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

Either, you can make up XLFDs from the results of XftListFonts

Or, a hack that I remember Keith Packard mentioning using in one
of his patches - he simply put the truetype fonts in his font
path, let the program use XListFonts as before, and then when
a request to load a font was made, looked to see if there was
a truetype font that corresponds.


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