[Fontconfig] alternate names [was: Two missing features]

[Keith Packard]

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