[Fontconfig] Localizing font family and style names

Phil Race Phil.Race at Sun.COM
Tue Nov 30 07:08:52 EST 2004


If the names are used to populate a font menu for example, then
its important that there's some way to select the name that's
most appropriate for the user's locale.

But also we allow an app to say what is the most appropriate
name for Locale "X". So we need that tag which says what language
a particular name is appropriate for.

I have come across fonts that have ONLY a Chinese name,
so its impossible to insist on the Latin name being the name.
If the font doesn't have a Latin name, I don't know a good solution.
I suppose you could use the postscript name but that's not really
the right thing from the perspective of the Chinese user.

I agree enumerating the fonts multiple times, once for each name
would create a burden on apps. We'd end up having to resolve these
to file names to see that they were the same font, and even then
I'm not at all sure what we'd do when its a TTC file.

So I think providing 'all the names in one font' is the most useful.
Without that I know we'd not be able to use fontconfig for font
enumeration. We'd have to continue to parse the fonts ourselves
to extract that information.
[[Although so long as only family names are listed, then we need
to do that to extract the full face names too, ie add FC_FACENAME
or similar.]]

I agree it would probably be helpful to apps if the preferred name
were listed first, but identifying it could be tricky
If the cache was built as root in the "C" locale as part of some
install its possibly not going to give you the right answer.
I'm not sure if that's a real problem but it seems worth mentioning.


Keith Packard wrote:
> The TrueType font format (and probably others) permits family and style 
> names to be provided in multiple languages (using several national 
> encodings).  I've wanted to include a mechanism for making these available 
> to applications for a long time, in fact this remains the only release 
> blocking feature for fontconfig 2.3.
> I've got a couple of mediocre ideas and am searching for more; if we can't 
> manage to figure out something sensible, I suggest that we just ship 
> fontconfig 2.3 without this feature soon.
> I've had this idea that we must always provide a Latin encoded name for 
> every font, which immediately requires support for multiple names for the 
> same font.  Today, I'm wondering if it wouldn't just be easier to provide 
> a single name for each font and select that name in some straightforward 
> fashion from the list of available names.  I see the identification of the 
> 'native' name for the font as a requirement in any case, perhaps we should 
> simply make 'native' == 'sole' and be done with it.  In any case, the 
> questions here are whether we require Latin names and whether we support 
> multiple names for each font.
> If we do permit multiple names for fonts, we need to identify how those 
> names are reflected through the Fontconfig API.
> One possibility is to identify one name as the 'canonical' name which
> represents the sole element of the FC_FAMILY/FC_STYLE pattern element and
> to place the additional names in another pattern element.  This would
> permit 'smart' applications to discover these additional names for
> presentation purposes while not bothering 'dumb' applications.  However, 
> this would also make font matching problematic -- it would be tricky for 
> applications to figure out how to match fonts against non-canonical names, 
> and that seems wrong.
> Another possibility is to provide all of the names in the FC_FAMILY pattern
> element.  Order the list so that the 'preferred' name occurs first and 
> even naïve applications will end up presenting fonts in the right language.
> Listing would return all names and it would be up to the application to 
> sort through them to find the desired presentation.  This would require 
> some parallel property marking the language(s) for each name.  Fonts with 
> a single name would not need this additional property.
> A third possibility is to present each font multiple times, once for each 
> supported language.  A tag in the pattern would mark the languages for 
> each entry so that listing would be able to filter out names 
> appropriately.  The biggest issue here is the elimination of duplicate 
> names by somehow identifying the entries cooresponding to the same 
> font.  I think the combination of file name and font index should suffice, 
> but it would place a significant burden on applications to perform this 
> elision manually.
> If anyone else has another alternative, I'd love to hear it.  At present, 
> I'm leaning towards either the 'only one name' solution or the 'all names 
> in one font'.  The 'only one name' solution would be significantly easier 
> to implement and deploy, but seems less friendly to the user.
> -keith
> ------------------------------------------------------------------------
> _______________________________________________
> fontconfig mailing list
> fontconfig at freedesktop.org
> http://freedesktop.org/mailman/listinfo/fontconfig

More information about the Fontconfig mailing list