[Fontconfig] Localizing font family and style names

[Lars Knoll]

On Monday 29 November 2004 21:31, Owen Taylor wrote:
> On Mon, 2004-11-29 at 11:29 -0800, Keith Packard wrote:
> > 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.
>
> I select a font in the font dialog, it's saved in my preferences,
> I change locale and it stops working?
>
> A web page developer lists a font in a stylesheet, and it is only
> selected for user's in some locales?
>
> An application uses a font name, the next release of the font adds
> a new translation of the font name into a local language, and
> the font is no longer found?
>
> I strongly believe that fonts should have a canonical "programmatic"
> name that is basically independent of locale. Since this isn't a
> feature of font formats (well, other than postscript names), we can't
> truly provide this.
>
> But using the ASCII/Latin name as is done currently by FreeType for
> the primary name of the font comes close.

But the font might also be specified in the localized name. Windows commonly 
displays fonts localized to the locale of the user. These font names will 
most certainly also get used in documents, as there is no easy way to get the 
latin name of the font in the API.

In my experience users have two requirements: 
They want to see the localized font name (preferably in the language of the 
font, ie. a chinese font should have a chinese name).
On the other hand they want fonts that are used in a document to simply 
resolve correctly. This implies that while you might only show one font name, 
matching has to work against all of them (localized and english).

We actually had lots of problems with Qt on Windows because application 
developers were specifying a font to use somewhere in the application and 
Windows couldn't find it anymore after deploying the application in a 
different environment. The solution for us was to show the localized name, 
but make sure we also parsed the latin name out of the font and match against 
both. That solved all of the bug reports we had in this respect.

> > 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.
>
> I see non-canonical names as being primarily a user interface element.
>
> Though I guess the question is "how do Chinese-language web pages
> specify fonts"; if using Chinese language family names in chinese web
> pages is common, then that probably argues that matching against
> non-canonical names is important.

Judging from what Windows offers as font name in their API, a person working 
on a chinese locale will specify the font using the chinese name.

> Dan Williams (cc'ed) mentioned something to me about Word documents
> specifying names in non-ascii encoding. Though OpenOffice isn't
> currently using fontconfig properly, that might be more evidence.
>
> > 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.
>
> Can you do this in a way that isn't going to break existing applications
> that use the listing APIs?
>
> While invisibly matching against non-canonical names as a fallback might
> be neat, backwards compatibility is vastly more important.

How much do you think would really break if you match against both canonical 
and localized names? One can specify the mechanism in a way that for the 
second name only exact matches count. That should bring you on the safe side. 
At the same time fontconfig currently doesn't handle localized names at all, 
and this will IMO cause bugs for a lot of asian documents.

English names for asian fonts are often pretty bad and from what I know it's 
very hard to pick the correct one based on the latin name. We had lots of 
requests for localized font names in asian locales in the past and it seems 
to be a pretty important feature for them.

> > 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.
>
> I'd dislike this one quite a bit. Applications that want to do simple
> things should be able to do them simply. Plus it sounds hard to do
> this without causing further memory-footprint and time overhead.

I agree. The best solution IMO is the following:

Listing fonts should probably give either the localized or the latin name with 
the possibilty of retrieving the other one as well. Font matching should try 
both (or all if the font has several) names, as you otherwise will run in 
some trouble with documents created on Windows.

Cheers,
Lars