Re: improvement of font selection

[Kenichi Handa <handa m17n org>]

In article <1143473110 5299 10 camel fresnel dumbhippo com>, Owen Taylor <otaylor redhat com> writes:

>> Basically I agree with that.  But, my font requirement is
>> just "be sure to use correct OpenType fonts for such scripts
>> that require CTL".  Isn't it a general requirement?

> Yes, it's a long-standing known problem. Generally, it doesn't
> become a huge problem as long as some font for the script
> is explicitly configured in the fonts.conf aliases ahead of
> broken fonts.

Unfortunately, AFAIK, fonts.conf doesn't allow per-script
(or per-language) settings, and we can't say some font is
broken or not without specifying a script or language.  For
instance, FreeSerif.ttf has no problem with Latin, Greek,
etc, but not good for Tamil even if it contains Tamil
glyphs.  On the other hand, akruti1b.ttf is good for Tamil
but is broken for Latin (ASCII).  And, first of all, even if
we put akruti1b.ttf before FreeSerif.ttf, sorting may change
that order (or, am I wrong with that?  I don't know how
fontconfig score fonts).

> I probably misunderstood what you meant by avoiding FcFontSort...
> it sounded like you wanted to do something very different from
> it. FcFcontSort is Pango's font selection algorithm.

What I suggested is to use FcFontSetSort.  Actually,
FcFontSort delegates the actual sorting work to
FcFontSetSort.

>> At least, the curren font selection of Pango has
>> unacceptable unreliableness (it may selects an unusable
>> font).  I think my change is to make it acceptable
>> unreliableness (i.e. if there's an usable font, use it) with
>> a help of shaper's "cover" function.

> But, because of the trimming, it's likely that there will
> be a usable font, but you won't see it.

Ok, then I change my wording to "if there's a non-trimmed
usable font, use it".  My patch will work better if trimming
problem is fixed, but it still provides possibility of
improvement without that fixing.  Actually, I have many
Indic and SEA fonts but most of them have different
coverages in Latin or symbol parts, thus are not trimmed.

>> > If we need to extend the shaper interface, we need to extend
>> > the shaper interface.
>> 
>> Yes, "If we need to".  But, I don't think "we need to" for
>> the current problem.

> I'm not sure about that. Someone needs to investigate how
> things would work if we were doing our own trimming.

I can't follow your discussion.  The current main problem is
to allow shaper engine to select a preferred font among what
Pango finds.  That can be solved without extending the
current interface, can't it?

To improve which fonts Pango finds is another problem
(i.e. the problem of sorting and trimming).  It may or may
not require extending of the interface.

> I don't think you can simply pass trim=False, then use
> character-by-character coverage, because then you have to keep the list
> of 1000 fonts around forever.

Right.  That's why I proposed to exclude unusable fonts
before sorting with trim=False.  This pre-exclusion won't
work well for English.  Then, we may need to add a new API
for shaper engine to control how to do that if you don't
want to hard-code some special treatment for English.

---
Kenichi Handa
handa m17n org