GNU bug report logs - #59347
29.0.50; `:family` face setting ignored

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: 59347 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca
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 <at> heytings.org>
> cc: monnier <at> iro.umontreal.ca, 59347 <at> debbugs.gnu.org, bug-gnu-emacs <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.