2012-05-20
The XFT font naming issue
One of the subtle problems with XFT fonts is that they don't have canonical, broadly supported textual names. To explain this, I need to go back to old server side XLFD fonts to show what I mean and the difference between XLFD fonts and XFT fonts here.
Fundamentally XLFD fonts are specified by their name, right from the relatively low level library APIs on up. You get a handle to the font by asking for it by name, and the name you use is its standard canonical format XLFD name. This means that everything that deals with XLFD fonts fundamentally uses a standard textual identifier for them, and in turn this means that everything accepts the same name to specify a particular XLFD font.
(Now, there are aspects of this that are less than ideal. For instance, a program that starts with one font and wants to derive a bunch of closely related ones (eg the same font in different sizes or the same font in bold or italic) is going to be parsing the XLFD name for the font into its component parts, changing some of them, and then reconstituting this into new font names.)
XFT fonts do not work like this. While XFT fonts sort of have a standard format name due to FontConfig (cf the font names section), these names are not actually a fundamental part of how XFT fonts are used and specified; instead, XFT fonts are usually specified as a collection of attributes and properties. Your code does not ask for a font with the name 'Monospace-14', it asks for a font with family Monospace and point size 14 (and so on). How you go from a text name for a font to this collection of attributes is to a certain extent up to your program in a way that it was not for XLFD font names.
(This is of course convenient for programs that want to deal with a cluster of fonts; now they can just directly vary the attributes they care about, like the point size.)
What this has created is a situation where different programs can each have a different way of naming the same XFT font. Since it's to a large extent up to each program to turn a font name string into the collection of XFT font attributes that it will actually use with the API, each program can and often does do it differently. There's no guarantee that two different programs will accept the same XFT font name and there's no guarantee that a particular program will accept all of the theoretical features of XFT font name specifications that you'll find outlined in the Font Names section of the FontConfig user documentation. Programs are in fact free to be quite limited in what they accept (the practical minimum is family and point size, but even then the format can and does vary). You have to check the documentation for each program to see how it handles XFT font names, what format they're in, and what you can and can't put in a name. And the answers vary, a lot.
What this means pragmatically is that XFT fonts are more annoying to deal with than XLFD fonts if you're primarily specifying them by (text) name. In the XLFD era, you had a single name for a font and everything accepted it. With XFT fonts, you have multiple names for the same font and you have to work out how to format the name of the font so that today's program will accept it (if it will at all; if you need to specify advanced options, it may not). Also, some programs may require you to specify the font in multiple bits (they may have a separate argument or setting for the family and the font size, for example, instead of letting you put it in one name).