Localizing font family and style names

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


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

[Index of Archives]     [Fedora Fonts]     [Fedora Users]     [Fedora Cloud]     [Kernel]     [Fedora Packaging]     [Fedora Desktop]     [PAM]     [Gimp Graphics Editor]     [Yosemite News]

  Powered by Linux