[Fontconfig] Why does family under `Best score` differ from that under the preceding `Match Pattern`?
behdad at behdad.org
Tue Mar 8 00:51:31 UTC 2016
On Mon, Mar 7, 2016 at 8:52 AM, Raimund Steger <rs at mytum.de> wrote:
> But maybe that's not even necessary. Only the following properties have
> higher priority than strong family: file, fontformat, scalable, color,
> foundry, charset. Of these, only 'scalable' occurs in the pattern in your
> case as far as I can tell so it should be a good candidate. (Some people
> might wonder why 'scalable' has higher priority than strong family as the
> latter normally indicates a deliberate user preference, but let's keep that
> aside :-P)
I wanted that changed because Chrome was calling FcFontSort(), then
skipping bitmap fonts in the results because in their opinion, fontconfig
failed to respect their SCALABLE=TRUE request. This is BAD BAD BAD. So I
moved SCALABLE to be high priority such that when an app requests a
scalable font specifically, we essentially never return a non-scalable one
unless there's no scalable font to support the char...
I'm starting to think that maybe we need a new call that takes two patterns
in: one for scoring, the way fc-match works now, and another for filtering,
the way fc-list works. With that, you can filter to "only color", or "only
scalable", or "supports Persian" and match at the same time. Right now to
do this, one has to do a FcFontList, take the result and call FcFontSetSort
/ FcFontSetMatch. It just never happens, and is expensive as well.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Fontconfig