[Fontconfig] Localizing font family and style names

[Owen Taylor]

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.

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

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.

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

Regards
						Oen

-------------- 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/20041129/56f0044f/attachment.pgp