Re: Xft and Xrender support for GTK+ 1.2.8

[Owen Taylor <otaylor redhat com>]

Keith Packard <keithp keithp com> writes:

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

What do you see as the difference between 'composite fonts' and
'fontsets'?

>From the point of view of Pango, there is a need to be able to dive
inside a 'composite font' or 'fontset' and access the individual
fonts, because when doing things like interpreting OpenType
tables, Pango sees a font as more than a simple collection of
glyphs.

That doesn't mean that from an application point of view / configuration
file point of view, the model can't be quite simple.

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

The real problem with the fontset situation is that, in particular,
for displaying input method feedback, we actually need a core
font set to pass to the input method. 

[ The GTK+-1.2 method for displaying input method feedback is
over-the-spot input; the input method puts up a borderless window over
the input location and draws on it a style that is supposed to
match how the application is drawing. ]

Now, perhaps simply always using the same core fontset for this and
letting it diverge from the Xft font specification is the best
that can be done. Maybe you could define some special fontset 
syntax which specified both the 

 -first-classic-xlfd-,second-classic-xlfd-|-xlfd-for-xft-
 
But I think any solution will be an ugly one.

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

I can't really disagree with this. I don't want to see things burdened
with too much compatibility code for XLFDs, bitmap fonts, XOM/XIM,
etc. A clean break is my ideal. But I'm afraid these spectors will
still be haunting my life for years to come, and so there probably
is the need to make provisions for handling them.
 
> > (Does an italic f have a positive or negative rbearing? From the way
                                                  ^
[ As Keith seems to have caught on, I meant lbearing here ]

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

It certainly possible. Though I'd still guess that it was a random
arbitrary choice, even if it was made at some earlier point than
when the X spec was designed. :-)
 
> > 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.

Documentation. Now there's an idea!
                                        Owen