Re: Why does family under `Best score` differ from that under the preceding `Match Pattern`?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Mar 7, 2016 at 8:52 AM, Raimund Steger <rs@xxxxxxxx> 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.

_______________________________________________
Fontconfig mailing list
Fontconfig@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/fontconfig

[Index of Archives]     [Fedora Fonts]     [Fedora Users]     [Fedora Cloud]     [Kernel]     [Fedora Packaging]     [Fedora Desktop]     [PAM]     [Gimp Graphics Editor]     [Yosemite News]

  Powered by Linux