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

[Eli Zaretskii <eliz@gnu.org>]

> 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.