Re: A new font layer ??

[Owen Taylor <otaylor redhat com>]

Changwoo Ryu <cwryu@debian.org> writes:

> Now I'm very tired of contacting authors, who wrote GTK+ programs
> which use just gdk_font_load() and/or GtkFontSelection dialog.  Such
> programs simply can't display CJK or iso-8859-N (n > 1) encoded text.
> They can be easily fixed, but it is just a pain to insert Cyrillic,
> Chinese, Korean, Japanese, ... font mappings into every applications's
> C codes.
> 
> How could we reduce the amount of this localization work?
> 
> Don't we need a new font API, which is quite different with X's one?
> (IMHO, X's font/fontset API is too compatible with the ancient X.)

Well, this is all part of GScript / Pango.

Basically, GScript will have a font abstraction that can
layer on top of any reasonable font system, then there will
be a wrapper that tries to make X look a bit like a reasonable
font system.
 
> I hope remembering "Times" be sufficient to load appropriate font or
> fontset, according to each locales.

Exactly.

Well, for GTK+ 1.4, I'd like to move away from the idea of
having different fontsets for each locale.

Logically, a font/fontset is just a collection of glyphs.
The selection of glyphs from the fontset may depend on
locale, but the collection of glyphs should not.

But beyond that, I'd agree that we need to make things easier
on the user. GtkFontSelection gets pretty unusuable
when you have fonts with more than one character set installed
on a system.

Some problems that need to be addressed when coming up with
a solution.

 - When new fonts are installed on the system, they should
   be automatically accessible. (If I install, say a truetype
   font of Verdana on my system, I should not have to edit
   some magic configuration file to make it accesible).

 - Scaling bitmap fonts should be avoided whenever possible

 - The need to have fallbacks to fonts that include extra
   glyphs should not affect the ability to use fonts
   that only include a subset of glyphs.

The last two considerations come into fairly direct confrontation
in some cases. 

 - In a terminal, what happens when the user wants to use a 12 point
   font, but only has 16 point Japanese fonts installed on their system. 
   If the user is not going to use Japanese, then increasing
   the line spacing for all lines on the terminal to accomodate
   16 point fallbacks would be wrong, so in this case, 
   if a Japanese character is encountered, you either want
   to display a "Unknown character" character or scale the 16
   point font to produce a (pretty much unreadable) 12 point
   representation  of the Japanese character.

 - In a web browser, in the same case, you don't require uniform
   spacing of all lines, so the right solution is to just
   increase the spacing of the particular lines that include
   Japanese characters.

GtkFontSelection already has a lot of the logic you need
to map X fonts to something more user-comprehensible.

It turns a XLFD into a:

 Family name (+ foundry if there are multiple such families)
 Style name
 Size

Triplet. This is almost right. The main problem that it has
it it puts the encoding into the same area as the Style
name. 

If instead of this, it created a fontset with wildcards
for the encoding fields, and if the result was exposed
to programs as part of the font API instead of just through
the UI than that would be pretty close to right.

Well, pretty close. A lot of times, the fonts you want
in a fontset don't actually have the same family name,
not to mention the same foundry. (Look at the gtkrc.*
files from GTK+)

It may be sufficient to supply a set of default aliases for the common
font sets - basically make the system adminstrator / vendor figure out
what the right fallbacks are for the ; another approach would be to
match fallbacks by something like Panose number. (Though 
XLFD's don't contain sufficient information for that :-()


There would have have to be a set of hints when loading a
fontset at a particular size indicating whether when a character
is not available at a particular size, whether it should:

 - Scale the bitmap
 - Use a "unknown glyph" character
 - Use a bigger size.

There also needs to be extended metrics operations to figure
out logical ascent and decent of a particular string of
glyphs - right now we assume that the logical height and
width of a font is the same for all glyphs.

Anyways, as you can tell, I have a lot of thoughts on this
issue, but not too many answers yet.

Regards,
                                        Owen