[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#59347: 29.0.50; `:family` face setting ignored
From: |
Eli Zaretskii |
Subject: |
bug#59347: 29.0.50; `:family` face setting ignored |
Date: |
Tue, 22 Nov 2022 19:44:27 +0200 |
> Date: Tue, 22 Nov 2022 15:41:47 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: monnier@iro.umontreal.ca, 59347@debbugs.gnu.org, bug-gnu-emacs@gnu.org
>
> No, it won't reject valid fonts (unless I misunderstand what you mean by
> "valid font"). For example, when searching for a font in the monospace
> family, all fonts in the monospace family are considered. If no such
> fonts are found, Emacs tries again (see face-font-family-alternatives) and
> considers all fonts in the courier family. If no such fonts are found,
> Emacs tries again and considers all fonts in the fixed family. After
> which Emacs gives up.
I feel like we have no focus in this dispute, and no real understanding of
the goal. So let me go back to your scenario and ask you: what exactly is
the problem with the scenario that you described? A reminder:
(set-face-attribute 'default nil :font "Source Code Pro" :weight
'ultra-heavy) ;; 1
(set-face-attribute 'default nil :font "Source Code Pro" :weight 'heavy) ;; 2
(set-face-attribute 'default nil :font "Source Code Pro" :weight 'ultra-bold)
;; 3
(set-face-attribute 'default nil :font "Source Code Pro" :weight 'bold) ;; 4
(set-face-attribute 'default nil :font "Source Code Pro" :weight 'semi-bold)
;; 5
(set-face-attribute 'default nil :font "Source Code Pro" :weight 'medium) ;; 6
(set-face-attribute 'default nil :font "Source Code Pro" :weight 'normal) ;; 7
(set-face-attribute 'default nil :font "Source Code Pro" :weight 'semi-light)
;; 8
(set-face-attribute 'default nil :font "Source Code Pro" :weight 'light) ;; 9
(set-face-attribute 'default nil :font "Source Code Pro" :weight
'ultra-light) ;; 10
(set-face-attribute 'default nil :font "Source Code Pro" :weight 'thin) ;; 11
(If you don't have the Source Code Pro font on your system, I'm sure you
can find another font with more weight variants with which you will
observe a similar effect.)
With current master, the variable-pitch face is realized as follows:
- with 1-3: -ADBO-Source Code
Pro-black-normal-normal-*-29-*-*-*-m-0-iso10646-1, which is a monospace font
- with 4: -PfEd-DejaVu Sans-bold-normal-normal-*-29-*-*-*-*-0-iso10646-1,
which is a variable pitch font
- with 5: -ADBO-Source Code
Pro-semibold-normal-normal-*-29-*-*-*-m-0-iso10646-1, which is again a
monospace font
- with 6: -urw-nimbus sans
l-regular-r-normal--29-210-100-100-p-158-iso8859-1, which is a variable pitch
font but without anti-aliasing
- with 7: -PfEd-DejaVu Sans-regular-normal-normal-*-29-*-*-*-*-0-iso10646-1,
which is a variable pitch font
- with 8-9: -ADBO-Source Code
Pro-light-normal-normal-*-29-*-*-*-m-0-iso10646-1, which is again a monospace
font
- with 10-11: -PfEd-DejaVu
Sans-ultralight-normal-normal-*-29-*-*-*-*-0-iso10646-1, which is a variable
pitch font
Is the problem that you expected the family to be DejaVu Sans, but you got a
different family in some cases?
Or is the problem that you expected a variable-pitch font, but got a
monospaced font in some cases?
Or is the problem something else?
And why is this result:
- with 1-5: -PfEd-DejaVu Sans-bold-normal-normal-*-29-*-*-*-*-0-iso10646-1
- with 6-7: -PfEd-DejaVu Sans-regular-normal-normal-*-29-*-*-*-*-0-iso10646-1
- with 8-11: -PfEd-DejaVu
Sans-ultralight-normal-normal-*-29-*-*-*-*-0-iso10646-1
better? You asked for ultra-heavy and heavy weight, but got bold -- why is
that TRT? what if it really mattered to you to have several fonts of
different heaviness?
You also mentioned this:
> Nothing tells it to reject fixed-pitch fonts as a last resort indeed.
> But clearly the code should not select a fixed-pitch font _because_ it is
> the only available font that supports say a 'semi-bold' weight, when
> variable pitch fonts that support a 'bold' weight are in fact available.
Why is it "clear" that font selection should do what you expect here, given
that the only (weak) indication that we are after a variable-pitch font is
the family? Why do you consider it so preposterous that Emacs comes up with
a semi-bold font, when you ask for a semi-bold font?
> Of course the weight of the default face should influence the weight of
> all other faces. But not to the point that a 'bold' variable pitch font
> is never even considered as a potential candidate for the variable-pitch
> face.
How do you know it wasn't considered? Maybe it was considered, but "lost"
to what Emacs decided to be a better candidate? And again, there's no
information of any kind in the font-spec we use that we are looking for a
variable-pitch font. We only have the family. Given that no font in the
family matches the specified width, why shouldn't Emacs try to find a font
from another family that does match the width?
> It's not that it doesn't produce satisfactory results, it's that it
> doesn't do what it is meant to do. The scoring mechanism for the
> weight/slant/width attributes is simply bypassed. Without unsetting these
> three attributes, font_list_entities only produces candidates that are
> exact matches (e.g. only "bold" fonts are returned), and the whole point
> of scoring ("when searching for a semi-bold font, bold is better than
> medium and worse than extra-bold") is entirely lost.
The fact that we bypass scoring and look only for exact matches might be a
valid criticism of the existing font-selection algorithm, but it doesn't yet
tell us what should be the alternative. To decide what would be such an
alternative, we need a good understanding of the goals of the font search in
the various use cases we need to support. Which is why I'm asking all those
questions.
> My patch simply restores the scoring mechanism (and fixes at least three
> bugs: 37473, 57555 and 59347).
Unfortunately, I've seen too many changes in this area which solved a couple
of problems, only to produce others, which took us time to discover. The
last thing I want here is to do the same for the N+1st time. So let's first
try to determine what exactly do we want to happen and why.
Thanks.
- 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 <=
- 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, 2022/11/22
- 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