Re: Xft and Xrender support for GTK+ 1.2.8

[Keith Packard <keithp keithp com>]

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

This should map easily to my new Xft ideas but will need some additional
functionality.  Xft will map arbitrary character encodings to arbitrary 
fonts through a unicode intermediate representation.  As most TrueType 
fonts expose a Unicode mapping, there isn't really all that much work to 
be done except expose iconv-based APIs for applications.

The additional work needed is to create either composite fonts or 
'fontsets' able to map the necessary subsets of the 10646 space.  I 
suspect the Han-contingent would rather have fontsets than composite 
fonts, but it seems like quite a kludge to me.

> - In order to keep legacy applications happy, we need to keep Xft
>   fonts corresponding closely in naming to core fonts

Xft provides enough configuration to make this relatively straightforward, 
you can even override the Xft configuration to "fix" it for Gtk apps.

Xft can also access core-fonts; Gtk could use only Xft for font access 
while still using XLFD names and exposing X font objects to applications 
where necessary.

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

But could be a fontset if necessary; I envision needing those for any 
2022-based applications unwilling to switch to unicode.

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

If working on Xft integration for GTK+-1.2 will help create better APIs in 
Xft, then we should at least spend the time doing a relatively complete 
design, even if we leave (some of ) the implementation work undone.

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

The definitions were taken from the red book; I assumed they carried some 
traditional interpretation from mechanical typesetting, in particular, 
negative LSB glyphs are pretty hard with lead type.

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

I'm not planning on changing it; I think the most useful thing would be a 
diagram in the document describing the sign and magnitude of the various 
fields.

keithp keithp com	 XFree86 Core Team		SuSE, Inc.