[Fontconfig] Localizing font family and style names

[Owen Taylor]

On Tue, 2004-11-30 at 10:51 +0100, Lars Knoll wrote:

> > 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).

Well, what name is displayed to the user is essentially independent
of what is in the document. Only in a few cases do users actually hand-
create documents and deal with font names.

> 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.

That's the type of bug I'd like us to avoid with fontconfig. The "name"
of a font should never depend on locale.

> > > 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.

My concern here was not in matching, but in listing. fontconfig is a
fairly rigid abstraction, so the two aren't independent.

I agree that matching against localized font names is important, but
what I'm saying here is that if it's going to confuse legacy apps
to have them in FC_FAMILY, then it needs to be done as a separate
element. (*)

But if Keith can figure out how to provide multiple font names in 
FC_FAMILY in a way that legacy apps won't get confused, that's even
better.

Regards,
						Owen

(*) Side issue is that TrueType fonts allow the localization of style
    names, don't know how that fits into the picture. It doesn't
    really matter for Pango, since Pango canonicalizes to a fixed
    set of style names that can be translated with gettext().

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/fontconfig/attachments/20041130/8af2f331/attachment.pgp