fontconfig-2.2.97

Mon, 02 Oct 2006 22:05:43 -0700

Fontconfig 2.2.97 released

I've spent much of today reading through fontconfig bugzilla and trying to fix bugs. Many of them had already been fixed or had patches attached. That certainly made things easier.

But, the big changes in 2.2.97 are a result of a pleasent development effort via email over the last week resulting in definitive action on how to handle multi-lingual names in fonts (style, family and fullnames). I'd been stalled on this since last year, trying to figure out a way to make existing applications “just work”, and somehow present nice localized names wherever possible.

As usual, the right answer was to punt and let some other software sort things out. Fontconfig isn´t the right place to try and localize font names; it doesn´t know what language should be used to present each font name. For most users, the right font depends more on the expected target languages of the font than the locale the user is running in:

For users not facile with a particular language, presenting fonts designed primarily for that language with an obviously foreign name helps them sort “useful” fonts from “useless” fonts.
For multi-lingual users, presenting fonts for each language in that language ensures that the font names are as accurately represented as possible.

This logic relates solely to family names. For style names, it's necessary to always present them in a language understood by the user. For now, that probably means using the current locale as we have no other notion of user languages.

I think some of this demonstrates a fundemental limitation of the locale system—it can't represent users facile with more than one language. I'd like to know whether we can fix this somehow; it seems wrong.

In any case, fontconfig now presents applications with two parallel lists, one containing the names (in UTF-8 encoding, of course), the second containing the language of each name. I used parallel lists because the alternatives all seemed a lot worse; the data is nominally informative, not normative, and has no place in the list or match process.

Applications are free to grub through the language list to select an appropriate name to present to the user. I'm hoping developers will propose some interfaces to add to fontconfig to make this easier; I'd rather let the users figure out the interface than attempting to produce one without an actual use case (or two) in front of me.

There are lots of other changes in fontconfig now:

it includes 'fullname' information where different from family or family+style.
it digs out the underlying font format (using the X-specific FreeType API added for X font servers).
it grubs through the silf and gsub/gpos TrueType tables to find out what layout support is present in each font.
the selectfont configuration element was added to let people control which fonts are available for applications to choose from.

Change logs and source are available (as usual) from the fontconfig.org website.