[Fontconfig] Localizing font family and style names

[Keith Packard]

Around 15 o'clock on Nov 29, Owen Taylor wrote:

> I select a font in the font dialog, it's saved in my preferences,
> I change locale and it stops working?

No, the idea was to identify the 'native' name for each font and use that 
everywhere.

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

That would be possible, but it seems unlikely that a font would suddenly 
sprout a 'native' name when previously it had none.  I suppose this could 
happen is if the font was originally distributed in Type1 format and 
provided only a Postscript name and then was converted to TrueType and had 
the native name added.  However, this is just as likely to result in a 
change in the English family name; Type1 fonts often provide only a full 
face name from which the family must be extracted.

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

Yes, locale independence is an absolute requirement.  But, that doesn't 
demand that we use the same language for every font.  Identifying the 
'native' name for the font would permit us to have both a canonical name 
and a suitable presentation for the expected target audience.

> But using the ASCII/Latin name as is done currently by FreeType for
> the primary name of the font comes close.

FreeType doesn't really identify the ASCII/Latin names correctly.  
Fontconfig has to grub around in the font to try and identify a suitable 
candidate.  And, Fontconfig currently lacks the ability to transcode names 
from non-Unicode encodings; dealing with localized names will require 
the use of iconv.

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

Yes, I've seen this as well.  A canvas of font names used on web pages 
might be useful here to see how prevalent the English names of these fonts 
are.

> > Another possibility is to provide all of the names in the FC_FAMILY pattern
> > element.
> 
> Can you do this in a way that isn't going to break existing applications
> that use the listing APIs? 

I think it's a requirement that we make it work with existing applications 
(unless that proves impossible).  Pattern elements can contain multiple 
values; applications (presumably) examine only the first value in each 
element, so placing the 'right' name in this location should make things 
just work. 

The selection of 'right' is problematic.  While it would be nice to sort
these based upon current locale (or lang tag specification), I'd really
like to leave things in fixed order and provide a convenience function to
extract the 'appropriate' presentation name in each environment.

> > A third possibility is to present each font multiple times
> 
> 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.

The appeal here is precisely to avoid the above issue of potential 
incompatibility.   Presenting these fonts multiple times ensures 
compatibility with existing applications while also permitting changes in 
applications that would produce better results.

But, if the effort for making this acceptable to users is greater than the 
effort for using a less compatible mechanism, then I suspect we should 
look elsewhere for a solution.

-keith


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/fontconfig/attachments/20041129/70d1fbfc/attachment.pgp