Around 16 o'clock on Oct 16, Juliusz Chroboczek wrote: > I suggest a new property of FcFonts that holds an a-list of all the > alternate names. Naive applications will only get the primary name; > wiser applications will get all the names. That will complicate matching semantics quite a bit -- you'll want to consider matches against either the primary name and the alternate names as equivalent in matching priority. What I could do is have the existing FcFontList API return only one name (primary? alternate for current locale?) and then provide another API to return other names (provide a language tag? return all names?) > We also need an API to get a font by another name; scanning all fonts > and building a database of all alternate names is of course > prohibitive. I suggest having two variants of the font listing > interface, one that only considers primary names, one that uses all of > the names. If we place all of the names in the FC_FAMILY entry, then the existing listing code will work correctly as-is. The only question is what values are returned by FcFontList. I think it would be nice if it returned localized names by default, but I can see arguments for having it always return names that can be represented in ASCII (or Latin-1). > (OT: is there any way the application can find out whether the font > database has changed since a given date? That would be useful for > applications wishing to cache font-related information.) Not directly. You can use FcConfigUptoDate to see if the configuration needs to be re-read, or you can use FcConfigGetConfigFiles and FcConfigGetFontDirs to retrieve lists of filenames that encompass the whole configuration state. Stat'ing those will let you compute when the configuration may have changed. > The issue has come up already when we were trying to do all fonts > localisation (including core fonts) through fontconfig; you want fontconfig > to provide you with the XLFD name when it cannot be easily derived from the > fonts real name. I'm assuming you mean the XLFD-modified family name here, and not the complete XLFD name. For the complete XLFD name, I'd like to figure out what additional properties are necessary to accurately compute that string. > I have no doubt that people will come up with other strange needs. XLFD is probably the strangest of them... -keith
