Re: Xft and Xrender support for GTK+ 1.2.8

[Keith Packard <keithp keithp com>]

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

Xft is getting a complete restructuring to support i18n better.  My plan 
is to unify glyph encodings as Unicode and use iconv to get from the 
application encoding to a unicode glyph encoding.  Underneath this 
encoding layer, the glyph indices will be exposed for applications which 
need access to unencoded glyphs.  

My exposure to even the Han-unification forces within the Unicode world
seem to support this radical architecture, given the ability to select
appropriate fonts for each Han glyph.

This means that FontSets could always use the same encoding for each font 
but the fonts would span different subsets of the UCS space.

I'm still puzzling over these issues, and would be grateful if others 
could bring existing application problems forward to help design more 
useful APIs in this case.  There's a rather large number of ways this 
could be done, but only a few useful ones.

Qt uses UTF16 internally, so having Xft expose a raw UTF16 API should make
Qt easy to port.  I'm very interested in learning what GTK 1.2 needs so 
that the appropriate interfaces can be built into the design rather than 
being bolted on later.

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

Yes there is:

	typedef struct _XGlyphInfo {
	    unsigned short  width;		/* bounding rect width */
	    unsigned short  height;		/* bounding rect height */
	    short           x;			/* bounding rect x */
	    short           y;			/* bounding rect y */
	    short           xOff;		/* escapement x offset */
	    short           yOff;		/* escapement y offset */
	} XGlyphInfo;
	
XTextWidth is the same as 'xOff' in the above structure.  I am begining to 
agree that I should have used measurements consistent with core X instead 
of using graphical values.  Even I find these confusing.

keithp keithp com	 XFree86 Core Team		SuSE, Inc.