[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
- bug#59347: 29.0.50; `:family` face setting ignored, (continued)
- bug#59347: 29.0.50; `:family` face setting ignored, Eli Zaretskii, 2022/11/22
- bug#59347: 29.0.50; `:family` face setting ignored, Gregory Heytings, 2022/11/22
- bug#59347: 29.0.50; `:family` face setting ignored, Eli Zaretskii, 2022/11/22
- bug#59347: 29.0.50; `:family` face setting ignored, Gregory Heytings, 2022/11/22
- bug#59347: 29.0.50; `:family` face setting ignored, Eli Zaretskii, 2022/11/22
- bug#59347: 29.0.50; `:family` face setting ignored, Gregory Heytings, 2022/11/22
- bug#59347: 29.0.50; `:family` face setting ignored, Eli Zaretskii, 2022/11/22
- bug#59347: 29.0.50; `:family` face setting ignored, Gregory Heytings, 2022/11/22
- bug#59347: 29.0.50; `:family` face setting ignored,
Stefan Monnier <=
- bug#59347: 29.0.50; `:family` face setting ignored, Gregory Heytings, 2022/11/23
- bug#59347: 29.0.50; `:family` face setting ignored, Gregory Heytings, 2022/11/30
- bug#59347: 29.0.50; `:family` face setting ignored, Eli Zaretskii, 2022/11/30
- bug#59347: 29.0.50; `:family` face setting ignored, Gregory Heytings, 2022/11/30
- bug#59347: 29.0.50; `:family` face setting ignored, Gregory Heytings, 2022/11/22
- bug#59347: 29.0.50; `:family` face setting ignored, Gregory Heytings, 2022/11/22
- bug#59347: 29.0.50; `:family` face setting ignored, Eli Zaretskii, 2022/11/22
- bug#59347: 29.0.50; `:family` face setting ignored, Eli Zaretskii, 2022/11/22
- bug#59347: 29.0.50; `:family` face setting ignored, Gregory Heytings, 2022/11/22
- bug#59347: 29.0.50; `:family` face setting ignored, Eli Zaretskii, 2022/11/22