[Fontconfig] Exposing match level

[Behdad Esfahbod]

On 15-05-09 03:35 AM, Raimund Steger wrote:
> On 05/08/15 20:29, Behdad Esfahbod wrote:
>> Hi all,
>>
>> I'm sure most of you who have been around know that it's been a very common
>> request to want to know whether fontconfig found a match for a request or just
>> fallbacks.  I've been thinking about this a lot recently, and like to make
>> sure we fix it this time.
> 
> This sounds interesting. The recent discussion about LilyPond reminded me that
> while fontconfig does have FcFontList(3) and FcFontSetList(3) to query fonts
> without any scoring at all,
>

> (1) this is normally not exposed by higher-level libraries;
> 
> (2) this doesn't sort regular variants near the top (obviously), so
> FcFontMatch(3) has to be called at some point anyway;

Right.  I was thinking last night that we might even be able to close the gap
between FcFontList and FcFontSort in the future.  If for every specified
element in the pattern the user can say how strict of a requirement that is,
one end will become FcFontList, the other FcFontSort.  Users can then have,
say, strict requirement for FC_SCALABLE, but non-strict for others, that
essentially filters out bitmap fonts, a feature many clients need and
currently implement incorrectly by calling FcFontSort() and filtering out the
bitmap fonts.


> hence improving FcFontMatch(3) and FcFontSort(3) might indeed be worthwhile.
> 
> At the moment, whether a configuration rule uses prepend_first v. prepend v.
> append v. append_last might carry a meaning of 'approximate' v. 'fallback'
> when a human reader examines the config, but not to the matching engine where
> everything is only a position in the property list. The 'fallback' boundary
> somewhere in that list is one purely of convention.

Correct.  I think we can use those rules to carry new information in the pattern.


> As long as the original documented purpose of the binding value in terms of
> fonts-conf(5) (that 'lang' could overrule 'family' in the match if the user
> explicitly stated the former, i. e. one of prioritizing property A over
> property B) is kept unchanged I think yes, it is possible to factor that
> meaning into the value.

Agreed.  Though, I still sometimes don't fully understand why that was desirable.


> To state it more explicitly, it is probably not a good idea to introduce
> strong family bindings into a pattern that didn't originally have them, by
> means of alias rules, only because we now think of binding as "how close is
> family A to family B". Such alias rules, where they specify binding="same"
> now, could only specify something like "same-or-lower" in the future --
> correct me if I'm wrong.

Spot on.  I was thinking about a binding="lower" kind of thing.  We can map
those internally to integers that keep going lower every time.

I'll copy/paste this message to the bug, lets continue discussion there:

  https://bugs.freedesktop.org/show_bug.cgi?id=90330

b

> 
> -Raimund

-- 
behdad
http://behdad.org/