Re: improvement of font selection

[Owen Taylor <otaylor redhat com>]

On Mon, 2006-03-27 at 17:14 +0900, Kenichi Handa wrote:
> Hi,
> 
> In article <1143211760 14491 122 camel fresnel dumbhippo com>, Owen Taylor <otaylor redhat com> writes:
> 
> > 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.
> 
> 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.

> > 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. 
> 
> I've proposed two things; patch to pango-context, and
> avoiding of FcFontSort.  But, I didn't propose any new
> font-sorting algorithm, and I don't understand what you mean
> by "configuration of language-specific fontsets".

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.

> >> > 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.
> 
> If there's really no performance problem in (1) and (2), and
> Pango can implement its own trimming efficiently, that's ok
> for me.  I just want Pango not to trim necessary fonts.
> 
> >> 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?
> 
> No, I don't think so.  It seems that
>    PANGO_ENGINE_SHAPE_GET_CLASS (engine)->covers ()
> always returns PANGO_COVERAGE_EXACT or PANGO_COVERAGE_NONE
> (at least on GNU/Linux), right?
> Then, my patch changes nothing.
> 
> When some shape engine implemets its own "covers" that may
> return PANGO_COVERAGE_APPROXIMATE on some fonts, the
> performance problem may rise, but it's only when a user
> doesn't have an "exact" font for a character he is going to
> render.  And, even in that case, if trimming is done
> properly, the "covers" function doesn't have to check 1000
> fonts but only 10 or more fonts.  I believe that's kind of
> inefficiency is ignoreable on a system where fontconfig's
> FcFontSort has no problem in sorting 1000 fonts.

OK, I thought I remembered that the basic shaper set an
"approximate" coverage, but I was misremembering. Indeed
there is no performance problem if all shapers return
EXACT or NONE. (Also no improvement.)

> > I'm not crazy about slowing down performance to get an 
> > inherently unreliable result.
> 
> 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.

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

Regards,
					Owen