bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#59347: 29.0.50; `:family` face setting ignored


From: Stefan Monnier
Subject: bug#59347: 29.0.50; `:family` face setting ignored
Date: Tue, 22 Nov 2022 15:47:50 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)

>> That's not what it does, no.  The loop in font_find_for_lface limits the 
>> number of fonts that are considered to some foundry, family, registry and 
>> additional style, and only considers more fonts if no suitable fonts have 
>> been found.
>
> But the same considerations apply to weight, slant, and width: shouldn't we
> prefer an identical value for each one of those, if that is possible?

The difference is that for numerical attributes there is a notion of
proximity (plus some arbitrariness: very few users care whether a font
is "normal" vs "regular" vs "medium", especially when the font of the
family you requested has only one of those 3 and the font designed
chose one of those three names somewhat arbitrarily).  This makes the
scoring work well for those.

In contrast, we don't have such a notion for family/foundry/registry,
which means scoring doesn't really work well for those attributes.

So I think it makes sense to rely exclusively on scoring for the
numerical attributes (width/weight/height/weight).  At least intuitively
it should give good results.  For me the question is what is its impact
in terms of the number of fonts we need to consider.

[ Side note: the slant attribute could also be made numerical, I think.  ]

> And if no suitable candidate is found by making these 3 attributes free,
> then we are back to the same problem, now with non-numerical attributes.
> Right?

Yes, but since they are not numerical/continuous attributes we can't see
those weird discontinuities where you get font A for `semi-bold`, then
font B for `normal`, then font A again for `light` (as in Gregory's
example) which makes no sense: either A is heavier than B or not, but it
can't be both, right?


        Stefan






reply via email to

[Prev in Thread] Current Thread [Next in Thread]