Re: Xft and Xrender support for GTK+ 1.2.8

[Owen Taylor <otaylor redhat com>]

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

> k> Qt uses UTF16 internally, so having Xft expose a raw UTF16 API
> k> should make Qt easy to port.  I'm very interested in learning what
> k> GTK 1.2 needs so that the appropriate interfaces can be built into
> k> the design rather than being bolted on later.
> 
> I think GTK+ 1.4 is the target you might do best to look at.  

Repeat after me:

 GTK+-1.3 is the development branch leading up to GTK+-2.0
 GTK+-1.3 is the development branch leading up to GTK+-2.0
 GTK+-1.3 is the development branch leading up to GTK+-2.0

Did everybody catch that?

 * There will be no GTK+-1.4 *

Clear? 

(Not to single you out - a lot of people are making this mistake,
despite us consistently saying GTK+-2.0 for 6+ months. Which is
why I have to yell about it here a bit.)

> The i18n
> interfaces in 1.2 are, er, confused.  Summary: you can use either
> 8-bit, 16-bit, or multibyte characters, with lots of redundant entry
> points and code.

Actually, I think they are more confusing than confused. There are
two types of GdkFonts in GTK+-1.2 - GDK_FONT_FONT and GDK_FONT_FONTSET,
which are created with different API calls.

 * If you have a font of type GDK_FONT_FONT, then you are drawing with
   8 or 16 bit glyph indices directly into the font. You do this
   with gdk_draw_string(). Whether 8 bit or 16 bit indices are used
   depends on whether the underlying X font is 8 or 16 bit.

   This works in internationalized settings only to the extent that
   the encoding of the font matches the multi-byte encoding of the
   locale.

 * If you have a font of type GDK_FONT_FONTSET, then you are drawing
   text strings in the encoding of the current locale. You can draw
   multiple strings with gdk_draw_text() or wide character strings
   with gdk_draw_text_wc().

   [ The effect of calling gdk_draw_text_wc() on a font of type
     GDK_FONT_FONT is undefined; it currently works OK for iso-8859-1,
     but not much else. ]

The question is, how do you map this onto Xft and get internationalization
working? I don't have much of an idea. Basically, internationalization
(certainly internationalization into Chinese/Japanese/Korean) only
works with fonts of type GDK_FONT_FONTSET. 

But its not easy to map the Xlib concept of a "FontSet" into Xft terms.
So, we get the nice sequences:
 
 - In order to keep legacy applications happy, we need to keep Xft
   fonts corresponding closely in naming to core fonts

 - The corresponding core font to an Xft font will be a single font,
   and thus of type GDK_FONT_FONT, not GDK_FONT_FONTSET.

 - Internationalization only works with fonts of type GDK_FONT_FONTSET.

Which is one reason why _I'm_ not working on Xft for GTK+-1.2.  (Along
with the fact that I think everybody would prefer if I spent my time
getting GTK+-2.0 out soon.) It probably is possible to have some
solution that breaks only a small number of applications, or if you
are willing to not support the CJK languages, then its not hard to get
something working.


> k> I am begining to agree that I should have used measurements
> k> consistent with core X instead of using graphical values.  Even I
> k> find these confusing.
> 
> It's not too late to change :-)

Pango uses the same system as X[mb/wc]TextExtents, which is to
return two rectangles, the logical and ink extents. A system
which is roughly similar to what Xft is using.

The advantage of this, is that you have only two rectangles, instead
of between 6-8 integer parameters. 

Yes, converting between these figures and the old style values is
a little confusing, so Pango includes macros:

#define PANGO_ASCENT(rect) (-(rect).y)
#define PANGO_DESCENT(rect) ((rect).y + (rect).height)
#define PANGO_LBEARING(rect) ((rect).x)
#define PANGO_RBEARING(rect) ((rect).x + (rect).width)

But I think it is, in general, easier to keep straight, and certainly
less ambiguous with the signs. 

(Does an italic f have a positive or negative rbearing? From the way
ascent/descent works, you'd think it was positive, but it turns out,
by the X definition to be negative.)

So, I'd rather not see Xft change, though the total amount of code
that it matters for me is about 3 lines in Pango.

Regards,
                                        Owen