Re: Xft and Xrender support for GTK+ 1.2.8

[Keith Packard <keithp keithp com>]

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

Largely a distinction between whether the Render GlyphSet contains glyphs 
from multiple faces or whether Xft composes multiple GlyphSets together in 
generating output.  The former might be somewhat more efficient, but the 
latter maps closely to XFontSets and might map better to ISO2022-based 
applications.

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

Oh.  You're still stuck with XIM for i18n input in GTK+1.2.  That's a pain.
I suggest letting the over-the-spot data appear in whatever font it likes 
and use Xft for native application text data.

> 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 

If Xft ends up with font sets, then the XLFDs that open core fonts should 
end up mapped to appropriate Xft fonts.  The whole Xft XLFD support should 
be viewed as a compatibility interface for applications built around XLFD.

Xft cracks the XLFD itself and matches core fonts using a separate
mechanism of weighted scores for each element of the font name.  This means
that even when matching the same set of fonts, Xft will often come up with
a different font than the X server would have when given the same XLFD.

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

Bitmap fonts are going to be here for a long time; FreeType2 has native 
PCF support that Xft will soon be able to use so at least we'll eliminate 
the fonts within the X server and have better matching along with 
automatic subsetting and reencoding.  Lots of languages can't yet be 
displayed with freely available outline fonts.

What I'd like to avoid is any relationship with XOM/XIM; I can't see 
building new toolkits using those mechanisms coupled with Xft.  I'm not
planning on adding any XIM/XOM extensions to Xft and recommend that we 
live with whatever XIM wants to do for applications needing it.

However, I don't believe that ISO2022-based applications will disappear 
and am still wondering if the fontset paradigm is a better fit for them, 
in which case Xft will need some sort of fontset notion.  I can't see how 
to display text containing Kanji and Hanzi with a single rendering call 
unless Xft can support Xmb-style interfaces.

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

My point was that the traditional metrics used for glyphs were probably 
selected so that they were all positive for lead type.

> Documentation. Now there's an idea!

Yeah, I've got lots of documentation to write.  I'd rather write papers 
than documentation any day.  But, even I am starting to get rather lost in 
the twisty maze of Xft/XRender functions and datatypes, writing 
documentation would both provide a reference and probably uncover some 
significant architectural inconsistancies better fixed today than a year 
from now.

keithp keithp com	 XFree86 Core Team		SuSE, Inc.