On Fri, 2007-10-19 at 21:34 -0400, Behdad Esfahbod wrote:
> Hi Owen,
>
> I've had this message of yours from last September in my inbox for quite
> a while, because I couldn't congest it the first time. Tonight I gave
> it another try and I still don't follow. Do you mind clarifying what
> the fontconfig change is about? More inline.
>
> On Sat, 2006-09-30 at 11:55 -0400, Owen Taylor wrote:
> >
> > The font selection algorithm for older versions of fontconfig is:
> >
> > 1) Explicitly specified non-generic fonts, in the order specified
> > (generic fonts being things like "sans-serif", "serif", "monospace")
> >
> > 2) Fonts from the generic in use matching the language tag of the text
> > sorted by the order that those fonts appear in the generic.
> > The generic in use is determined in priority order:
> >
> > - If one was given explicitly, that generic
> > - If a explicitly specified font is recognized as belong to
> > a generic class, that generic. (So, Arial pulls in sans-serif,
> > Courier, serif)
> > - Otherwise, sans-serif
> >
> > 3) Other fonts matching the language tag, in random order.
> >
> > 4) Other fonts from the generic in use.
> >
> > 5) Other fonts in random order.
>
> Ok, these make sense. And the final list is pruned, right?
Yes, I omitted that detail because it makes no user-visible difference.
> > If the language tag refinement scheme ended up with no language tag,
> > then 2) and 3) are skipped... this is what is going on when your
> > language is en-US.
> >
> > The fix in the most recent versions of fontconfig referred to above
> > is that 2) and 3) are replaced with:
> >
> > 2') The best font that matches the language tag of the text chosen as
> > the first language-tag matching font of:
> >
> > - Fonts from the generic use, in the order specified
> > - Other fonts in random order
>
> I don't understand this one.
>
> And which version of fontconfig was this introduced in?
commit 5cf8c5364f1b7a676f52b480fa55c571cadc6fda
Author: Keith Packard <keithp keithp com>
Date: Tue Dec 14 00:12:25 2004 +0000
I changed FcFontSetSort to respect the generic aliases better in
the face of language matching.
What I did was to ammend the strict sort order used by FcFontSort
so that it 'satisfies' the language specified in the pattern by
locating the best matching font supporting each pattern language
and then ignores language in the remaining fonts for purposes of
matching.
So, when asking for 'sans:lang=en', you'll get an English font
first, and then the remaining fonts sorted with respect to the
'sans' alias alone -- pushing Kochi fonts ahead of other
English-supporting Han fonts.
reviewed by: Owen Taylor <otaylor redhat com>
I don't know what version of fontconfig that corresponds to.
> > The advantage of that is that once we know what font we prefer for,
> > say, Greek, a language tag of Greek won't then won't reorder Russian
> > fonts to prefer fonts that also happen to cover Greek.
>
> And I don't get this either. So, you are saying that if we ask for
> fonts with lang=Greek but look for fonts supporting Russian in the
> result it will work as good as doing the same with lang=Russian?
So, say we have three fonts:
Nice font covering Russian
Nice font covering Greek
Ugly font covering Greek and Russian
Sorted in that order in the sans-serif alias in fonts.conf.
The way that fontconfig used to work, FcFontSort with lang=gr would
have given us:
Nice font covering Greek
Ugly font covering Greek and Russian
Nice font covering Russian
Because the Greek and Russian font was considered to be "better" than
the Russian only font. This forced us to do language tag refinement.
But the observation is that once Greek has been "satisfied" by one font,
there is no reason for fontconfig to reorder the rest of fonts, so newer
versions of fontconfig will instead give us instead:
Nice font covering Greek
Nice font covering Russian
Ugly font covering Greek and Russian
And we get reasonable results with the simple lang=gr language tag.
- Owen
Attachment:
signature.asc
Description: This is a digitally signed message part