Fontconfig has been under development for about a year, and is now ready for general use in new application development as well as porting existing applications. The interfaces provide enough abstraction that future binary compatibility should not be difficult, even in the face of significant changes to the internal architecture of the library. The documented interfaces should be able to remain stable for the foreseeable future, even while new functionality is added.
As each font covers only a subset of Unicode, applications wanting to display documents in multiple languages often need to use more than one font to display the entire document accurately. Fontconfig already has information about Unicode coverage for each font, so applications can specify a set of Unicode characters when selecting a font. This forces Fontconfig to return a font covering those characters if one is available.
Using this particular matching operation is tricky -- the usual situation is that the application has a particular font specified for the document, but portions of the document cannot be displayed with that font, and so additional fonts are required. If the application builds a pattern describing the original font and augments it with coverage information, then Fontconfig may return a very different font than the one requested. Select different coverage and another very different font may be returned. The problem is that the application has no idea which of these fonts are ``closer'' to the original font pattern. If additional characters need covering, the application does not know whether it should use one of the fonts it has already matched, or request yet another font from Fontconfig.
As an alternative, Fontconfig could provide a complete list of fonts, ordered by the distance to the original font pattern, without any Unicode coverage information. The application could then discover which font supporting a particular set of Unicode characters was closest to the pattern without needing to perform a match operation. This list would be trimmed so that only fonts with unique coverage would be included, limiting the number of fonts to examine.
An extension of this idea is to automatically perform glyph substitution within the Unicode APIs of Xft; that would make it easy for applications to avoid missing glyphs for particular characters. This per-glyph substitution does not generate ideal output, it is better to do font switching at the word or sentence level, so applications should be encouraged to perform better substitution themselves, but for simple applications, it is arguably better to have this support in Xft than no support at all.
The current Fontconfig matching algorithm was inherited from Xft; it was designed to provide a mechanism similar to cascading style sheets but without actually studying and duplicating that specification. As the differences are minor, and essentially unwarranted, the matching algorithm in Fontconfig will be changed to make performing CSS2-style matching more convenient.
There are aspects of CSS2 which Fontconfig cannot perform, in particular, it has no context in which to interpret terms like ``bolder'', ``larger'' or ``wider''. These must still be interpreted by the application. However, the weight fill-in and slant substitution specifications can easily be replicated, and the relative weight operators can be handled with some application assistance.
The resulting matching mechanism will be useful wherever CSS2 is used, and also provide a more accessible specification as developers and users become comfortable using the CSS2 font specification mechanisms.