Re: Font lookup ranges [was Re: Notes on Pango Xft backend]

[Owen Taylor <otaylor redhat com>]

Keith Packard <keithp keithp com> writes:

> Around 14 o'clock on May 28, Owen Taylor wrote:
> 
> > The one place where a fix is urgently needed is for Japanese
> > vs. Traditional Chinese vs. Simplified Chinese; things look pretty
> > awful there at the moment; but what I want to do first in that area
> > is make font selection locale/language-tag sensitive.
> 
> That means tagging sections of text with the language and exposing the 
> font language tags in the list of fonts I hand back.  Alternatively, you 
> can create separate lists, one for each language tag found for each 
> logical font. 

Pango already has the language tagging mechanism; the question is
how to use this to influence character lookup.

 a) Call FcFontSetSort() once, get a list, and then when finding
    a (language-tag, codepoint) pair, look first for a font with
    the language tag and the codepoint, then if that fails, 
    look for a font without the language tag with the codepoint.

    Problems:

     - Takes two passes to look up a character with a missing
       language tag. 
     - I don't think we should ever fall back to a font that wasn't
       explicitely specified (*), just for a want of a language 
       tag.

 b) Call FcFontSetSort() separately for each language, and somehow
    influence the sort order; what we'd like to do is make including
    the specified language tag have an weight:

     Less than whether the pattern is in the family
     Greater than the ordering of family names listed in the pattern

    Problems:

     - I don't think we should ever fall back to a font that wasn't
       explicitely specified (*), just for a want of a language 
       tag.

Problems with both:

 - Type1 fonts don't have OS/2 tables, and thus don't have FC_LANG
    entries; I think some TrueType fonts might miss them as well.

 - The set of languages in the OS/2 table / FC_LANG is pitfully
   small. On the other hand, all we really care about
   is Simplified Chinese/Traditional Chinese/Japanese/Korean
   so it may well be good enough.

   [
    http://mail.gnome.org/archives/gtk-i18n-list/2001-June/msg00001.html
    describes the form language tags take in Pango; some of the followup
    discussion is interesting; 

     http://mail.gnome.org/archives/gtk-i18n-list/2001-June/msg00010.html

    Clarifies what Pango language tags are for in response to 
    comments from Peter Constable.
   ]

You seem to imply a third possibility with:

> That might be best as I expect font pattern editing to be 
> used to select preferred faces for each language tag.

  c) Pango adds the language tag to the pattern it feeds to 
     FcConfigSubstitute, and fonts.conf does pattern matching magic
     to provide a different "Sans-serif" alias for every language.

Can't say I like this too much:

 - Requires lots of careful configuration (more than just
   slapping extra fonts into "Sans-serif".) Configuration is bad.

 - Would mean that the default config files wouldn't 
   use the simplified <alias> element, sort of ruining the point
   of <alias>.
     
Still, it has the decided advantage that it frees the mechanism
from relying on information in the font.

Regards,
                                        Owen


(*) Explicitely specified is a tricky concept:

    Say, we have two things in our fonts.conf

    a) Alias Sans to "Arial"
    b) If no generic alias is found in the pattern, tack on "Sans-serf"

    User specifies  Pattern becomes                  
    ==============  ===============
    Verdana         Verdana(a), Arial(b)
    Sans-serf      Arial(c) 

    (a), and (c) are explicitely specified, (b) isn't.
 
    Basically, we want family names that were explicitely given
    by the user, or family names where the expansion only involved
    <prefer> elements.