I thought this bug had been filed, but couldn't find (I listed all bugs filed
under fontconfig, resolved, new, unconfirmed or closed).
A number of CJK web pages specify font family names in CJK, but they're not
recognized by web browsers that rely on fontconfig. (for instance, see
http://bugzilla.mozilla.org/show_bug.cgi?id=223653). Besides, authors of other
applications/libraries that depend on fontconfig must be glad to be able to
present font names in 'native' scripts or localized form.
Here's a possible approach.
Hmm. That's an interesting approach -- changing the listing process to show
each font under every available name. I think that has a lot of merit as it
would ensure that even existing applications would see both names.
I don't see a problem with letting naïve applications get duplicate entries, so
the 'other_family' configuration element doesn't seem necessary.
I would like to see the following features included in this patch:
1) Mark each name with its language (or languages). I'd store this as a
parallel array within the font pattern. Use the existing string representation
for languages (do we need territories as well?)
2) Connect multiple entries in the returned list for the same font somehow so
that "smart" applications can present the duplicate fonts sensibly.
I suggest that the language of the family form no part of the matching process,
this really is just a matter for the listing API.
fontconfig now includes all names for the font, matching against any one of them.
Still to be done is some kind of API to help locate the "best" name for a
particular usage. I think I'm exposing enough information to let applications do
this match on their own; when we find a few common cases, we can fold them back