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

Previous Next

Full log

View this message in rfc822 format

From: Gregory Heytings <gregory <at> heytings.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: monnier <at> iro.umontreal.ca, 59347 <at> debbugs.gnu.org
Subject: bug#59347: 29.0.50; `:family` face setting ignored
Date: Tue, 22 Nov 2022 15:17:30 +0000

>> The variable-pitch face should use a variable pitch font, shouldn't it? 
>> Unless there are no such fonts installed on the computer of course, in 
>> which case it could fall back to a monospace font.
>
> You know it and I know it, but how should the code which examines the 
> fonts know it?  AFAICT, nothing tells it to reject fixed-pitch fonts. 
> Or did I miss something?
>

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 should the weight of the default face influence the font selected 
>> for the variable-pitch face
>
> Because if the default face is bold, so should be other faces, 
> preferably. To keep a consistent appearance, so to say.  And the same 
> goes for slant and width.
>

With the code on master, the effect is the opposite of consistence.  With 
the patch the effect is consistent: when the default face is say 
'semi-bold', a 'bold' variable pitch font can be considered the best match 
for the variable-pitch face.

>> to the point that even when variable pitch fonts are installed on the 
>> computer, they are all flatly rejected because they do not explicitly 
>> support say the 'semi-bold' weight?  The weight of the default face 
>> should only influence the weight of the other faces
>
> How are "other faces", where you agree that the weight should matter, 
> different from the variable-pitch face, where you don't agree?
>

What I said above was perhaps not clear enough.  There is nothing special 
about the variable-pitch face, I only used it to make the problem of the 
code on master as clear as possible.

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.

>
> Anyway, I'm okay with doing what you suggest as a fallback, if the code 
> we have now somehow didn't produce satisfactory results.
>

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.  My patch simply 
restores the scoring mechanism (and fixes at least three bugs: 37473, 
57555 and 59347).

>> With a 'semi-bold' default face, a 'bold' variable pitch font is a 
>> legitimate candidate for the variable-pitch face.
>
> But your patch doesn't "loosen" just one attribute, it does that with 
> all 3 in one blow.  Maybe if we "loosen" just one, we will be able to 
> find a match for the other two.  I don't think font_score guarantees 
> that, does it?
>

It does that because these three attributes are those that are considered 
by the font scoring mechanism (together with the size, which is set to nil 
two lines above).  The scoring mechanism guarantees that the best match, 
depending on the user preferences specified in face-font-selection-order, 
will be selected.

Previous Next

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