Swing's GTK look and feel does not expand the definitions of "sans", "serif",
"monospace" used via GTK. They are mapped to the JDK's definitions of these fonts.
What this means is that if they are mapped to different physical fonts - as is
typical - then the fonts in the GTK Look and Feel will not appear identical to
the ones in GTK apps - although their sizes will be correct.

In addition to the set of fonts which map these, fontconfig also provides
a way for an app to express a language preference, which it uses to give priority
in the returned list to fonts which support that language. Pango uses this, and
Pango text APIs are what used by GTK, so to be most compatible, JDK should do
this do.

Additionally fontconfig provides means to return additional information about
how the font should be rendered, such as prefer embedded bitmaps, or use LCD text,
n a per font basis which may over-ride a user's desktop settings. All of these settings
aren't in themselves sufficient. fontconfig doesn't do any rendering - it just
describes system/user preferences and configuration. Pango uses this information
in rendering requests using Xft and freetype.

So, by calling into fontconfig, JDK should be able to build JDK composite font
definitions which use the same fonts and exhibit the same rendering behaviour
as GTK.

Additionally when a physical font is specified in GTK, fontconfig is still used
to obtain fallbacks so that additional script support is present. This also
implies building a composite font and is almost identical to what already happens
in the windows look and feel.

###@###.### 2005-05-24 16:54:08 GMT