Re: improvement of font selection
- From: Owen Taylor <otaylor redhat com>
- To: Kenichi Handa <handa m17n org>
- Cc: gtk-i18n-list gnome org
- Subject: Re: improvement of font selection
- Date: Fri, 24 Mar 2006 09:49:20 -0500
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
> (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
> (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
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.
] [Thread Prev