[Fontconfig] Localizing font family and style names

[Owen Taylor]

On Mon, 2004-11-29 at 12:52 -0800, Keith Packard wrote:
> 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.

There are plenty of scripts used by many different languages. What's
the native name for a Arabic font with Persian, Urdu, and Arabic
names? It probably depends on who created the font...

What about a font that spans multiple scripts?

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

Doesn't strike me as unlikely that someone creating a font would start
off with a Latin name and only later figure out how to add additional
names. Other than CJK fonts, most of the fonts we ship with RHEL/Fedora
don't have localized names at all. 

If people start adding them, should things break?

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

I think that's an elusive concept. 

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

Hmm, I thought I remembered David Turner doing work to give FreeType
reasonable ASCII font name selection.

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

My plan for Pango is to only reveal localized names with a specialized
function like pango_font_face_get_display_name(). And maybe magically
make them work if used in font descriptions. 

Reordering based on locale seems like making things hard for everybody.

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

That's a very slim idea of "compatibility". A user is going to be
considerably more confused by seeing a font twice, as compared to 
seeing it once with a Latin name, I expect. The former is introducing
new weirdness. The former is just leaving current limited functionality
in place.

Regards,
						Owen

-------------- 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/ee14e44e/attachment.pgp