Re: improvement of font selection

[Kenichi Handa <handa m17n org>]

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?

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

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

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

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

Regards,

---
Kenichi Handa
handa m17n org