Re: Font priorities

[Owen Taylor <otaylor redhat com>]

On Tue, 2003-02-04 at 23:40, Keith Packard wrote:

> > Chronic: There is no reliable way for the user to specify 
> >  preferences as to what fallback fonts they prefer. Once 
> >  you get a fallback, you get the fallback that best matches
> >  the current language tag, even if that font is the ugliest
> >  font on the system.
> 
> That's a "feature", not a bug :-)
> 
> Of course, you can force the system to select a different font with a 
> strong binding value, but realistically, the goal is to make sure the font 
> selected has a prayer of displaying documents in the current language.  A 
> good looking font that is missing half of the letters in the text is worse 
> than a less desirable font which does have the needed glyphs.

Hmm, another angle on the problem is that when we do FcFontSort,
we end up with:

 Luxi Sans
 FreeSans
 Raghindi
 
With FreeSans being sorted above Raghindi because it matches the 
"en" language tag. But "Luxi Sans" has already taken care of
the "en" language tag. So, this sorting is completely bogus
from a user point of view (if not from a mathematical point
of view.)

> It may be that we need better mechanisms for selecting the document
> language; HTML has language tags which match fontconfig quite nicely and
> (generally) yield reasonable results.  Lacking better information, 
> fontconfig falls back to $LANG (et al.).  Perhaps there are better ways?
> 
> > Yeah ... I think for Pango's needs, a fontconfig key that was all
> > the tables in the TrueType file would probably be sufficient. 
> 
> Can you build that into a complete proposal?  I don't mind grubbing 
> through freetype sources, but I fear I'll miss something as I don't really 
> understand the whole picture.  Just a list of the possible values with 
> semantics should suffice for a start.

Will do.

> > Normally, "supports the user's default language" is a good heuristic
> > for choosing between two fonts that both cover the code points.
> > But sometimes it isn't ... so there needs to be a way of overriding
> > this ... the obvious thing (and the thing people expect) is that
> > being in the sans alias is a stronger indication of preference.
> 
> If the document isn't in the default language, then somehow we need to 
> tell fontconfig what language is in use; lying always gets you in trouble.

One possible thing we'll be able to do in future versions of Pango, is
that I plan to do script detection, so I'll be able to tell that
a run of text is in Devanagari ... if you then had a table mapping
from language => script, you could tell that the 'en' language
tag _couldn't_ be appropriate for the Hindi text, though you would
have no idea what language tag _was_ appropriate.

> The addition of $LANG handling to fontconfig could be seen as a hack; the 
> intent was that applications supply language information at all times.  
> Of course, pango has no clue about language, so it may be necessary to 
> expose that up to the application so it can select the right value.

GTK+ and Pango are always supplying language tags to Pango. Of course,
unless the app provides otherwise, those language tags are based off
of $LANG.

> I don't see any other reasonable way to support multiple Han languages in 
> one document; no amount of configuration will make that work automatically.

Yes, but that situation doesn't seem parallel to the situations here:

 - fontconfig ignores all the fonts in the sans-serif alias, and
   goes to a different one, because it has 'en' coverage. Even
   though fontconfig already found Luxi Sans for 'en'.

 - fontconfig ignores all the fonts in the monospace alias and
   picks a different non-monospace font when rendering some
   Roman text, because the language tag is 'ar'.

> Weak bindings were added precisely because the Sans alias shouldn't 
> override the document language, when the document language is accurate.

I would still argue that the problem here is that there should be a 
three level fallback system:

 - Applications specified fonts
 - Fonts specified as fallbacks in fonts.conf
 - Other fonts

Rather than the two-level scheme we have currently.

Will that allow handling all situations? No. But it gives people 
another  intuitive tool for dealing with the situations where 
fontconfig is making poor choices for fallback fonts.

Of course, I was never able to accompany this argument with a good way
to represent a three-level system as a scoring scheme in an elegant
way. But then again, I don't think people are really understanding
the weak/strong binding system, so any elegance for that is basically
an implementation detail.

Regards,
                                           Owen