Re: improvement of font selection

[Kenichi Handa <handa m17n org>]

Hi, thank you for the response.

In article <1143038214 3078 11 camel localhost localdomain>, Owen Taylor <otaylor redhat com> writes:

> The problem is fontconfig ... since we ask fontconfig
> to "trim" the results when calling FcFontSort(), only one
> Japanese (say) font will be returned. If there is another
> Japanese font further down the list, it won't be returned
> unless it has new characters that the previous fonts don't
> have.

Yes, I've noticed that problem and also the other problems.
In short, I think we should avoid using FcFontSort.

> So, I don't think your patch will work out reliably - 
> the font with "APPROXIMATE" or "FALLBACK" coverage may
> keep your "EXACT" font from being found at all.

> On the other hand, if you don't trim the results you'll get
> every single font in the system in the returned list, which
> would be horrible for performance and memory usage.

But the method used in FcFontSort has some problems
especially in such a case that we want Hindi fonts (several
are available) but there are a huge number of non-Hindi
fonts.

(1) It calculates scores of many unnecessary non-Hindi
    fonts, and sorts all of them.

(2) To trim it, it also checks charsets of such unnecessary
    fonts.

(3) The trimming algorithm is to check a charset against the
    union of all previous fonts.  Thus, if one previous font
    supports [a b] and another supports [a c], a new font
    supporting [b c] is excluded.  But, sometimes, what we
    want is a font supporting [b c].

> The right thing to do is probably duplicate the trimming code
> from fontconfig and combine it with our own logic ... if you
> look at how trimming is implemented in fontconfig, it's not
> doing anything that we could do ourselves as efficiently.

That doesn't solve the problem (1) above.  The way, I can
think of, to avoid the above problems is this (at least for
non English fonts):

1. Get a fontset by FcFontList() by LANG pattern.  Perhaps
   we must add "generic" fonts (for serif, etc; not that
   many) to the resulting list.

2. Use FcFontSetSort() on it without trimming.

3. Ask shaper to select the best one.

By the way, regardless of modifying Pango along that line or
not, I think the patch I proposed doesn't make the situation
worse.  And, even if it's not that reliable now, there
surely exist a case that the patch works.

> The other possibility - which could work Graphite and for 
> OpenType, but maybe not as well for you - is to get fontconfig 
> to sort the returned fonts based on what tables they contain,
> and thus prefer the fonts with silf or GSUB/GPOS tables.

Which OTF features are required depends on a
script/language.  So, to make that work, we need another
callback function in shaper to provide that kind of
information.  The above methods (step 1..3) I proposed
doesn't require such a change.

---
Kenichi Handa
handa m17n org