Re: Font priorities

[Owen Taylor <otaylor redhat com>]

On Tue, 2003-02-04 at 22:27, Keith Packard wrote:
> Around 21 o'clock on Feb 4, Owen Taylor wrote:
> 
> > The thing is, fontconfig, when deciding between Raghindi and
> > FreeSans for Hindi, says: FreeSans covers the current language, 
> > English, and Raghindi doesn't, lets' use FreeSans, even though
> > Raghindi is part of the Sans alias, and FreeSans isn't.
> 
> Fontconfig uses language to order font preferences; there's no other sane 
> way to choose between two otherwise similar fonts.  If Raghindi doesn't 
> support $LANG, then your application better let fontconfig know what 
> language you are interested in.

Well, there are two problems:

 Acute: fontconfig is picking fonts that don't have the right
  OpenType tables.

 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.

I think both need to be addressed.

> > I've been somewhat unable to convince Keith there actually is
> > a problem here, though I consider this a fairly major flaw
> > of the fontconfig scheme.
> 
> I think one issue here is only that pango wants OT tables and Fontconfig 
> doesn't provide a mechanism for selecting fonts based on that support.  We
> could easily add that.

Yeah ... I think for Pango's needs, a fontconfig key that was all
the tables in the TrueType file would probably be sufficient. 
Generally, "Covers Hindi codepoints and has a GSUB table" is
sufficient information. Unless for FreeFont they start adding
the OpenType tables piecemeal, and have the tables for Arabic
but not the tables for Hindi...

(FreeFont is just a bad idea... Unifying to a single font beyond
Roman-like scripts just doesn't make sense.)

But this still wouldn't address the question of preferences
for fallbacks.

> Fontconfig chooses fonts in the following order:
> 
> 	Strong binding matches
> 	Language matches
> 	Weak binding matches
> 
> "normal" substitutions in the config file generate weak bindings, normal 
> application APIs generate strong bindings.  This is intended to have 
> application (or user) specified fonts override language specifications
> while substitions found in the config file would not.  Otherwise, the 
> config file rules would end up selecting fonts inappropriate for a 
> particular language.
> 
> Is there some reason the document (or toolkit) can't specify an 
> appropriate language here?

I don't see how it could... the only reason that 'en' isn't the
appropriate language is because Stefan happens to have two Hindi
font on his system.. the bad one has English, the good one doesn't.

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.

Regards,
                                          Owen