Re: improvement of font selection

[Owen Taylor <otaylor redhat com>]

On Thu, 2006-03-23 at 14:24 +0900, Kenichi Handa wrote:
> 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].

If someone really has very particular font requirements, then
they probably should just specify them. A user can specify
a font of 

 "Palatino,Kochi Mincho"

And get exactly that. The more magic we do on font selection, the less
likely that the user will understand what's going on.

There's a pretty big advantage to being reasonably consistent
with the way fontconfig works in other programs. If we invent
our own font sorting algorithms, then we lose that advantage.

And I definitely don't want to introduce some Pango specific
configuration of language-specific fontsets. 

> > 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. 

But what's the problem in (1) or (2)? A lot of work has been done
to try and make that not a performance bottleneck, and it doesn't
generally seem to be one. If it works with 1000 Latin fonts,
then it should work with 1000 Latin fonts + 5 Hindi fonts.

>  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.

There's a performance penalty from the patch, right?

I'm not crazy about slowing down performance to get an 
inherently unreliable result.

> > 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.

If we need to extend the shaper interface, we need to extend
the shaper interface.

Regards,

					Owen