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

[Gregory Heytings]

> So let me go back to your scenario and ask you: what exactly is the 
> problem with the scenario that you described?  A reminder:
>
> 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?

The problem is that users expect a variable pitch font for the 
variable-pitch face (and an antialiased font when antialising is on). 
That's what the "family = Sans Serif" specification of that face means.

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

It is better because the "family = Sans Serif" specification of the 
variable-pitch face is obeyed.  (Incidentally, that result corresponds to 
the result returned by fc-match for those weights.)

> You asked for ultra-heavy and heavy weight, but got bold -- why is that 
> TRT?

Same answer: it is TRT because the "family = Sans Serif" specification of 
the variable-pitch face is obeyed.

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

You seem to misunderstand how font selection works.  The "family = Sans 
Serif" specification of the variable-pitch face is not at at all a "weak" 
indication that we are after a variable pitch font, it's the strongest 
possible indication that we are after a variable pitch font.  It means 
"please choose whatever font you want among those installed on the system, 
but one in the Sans Serif family", "Sans Serif" being one of the few 
generic font families.  It's like the "Monospace" family for the default 
font.  It would be wrong if Emacs decided to select a variable pitch font 
for the default face, wouldn't it?

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

I debugged the code.

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

See above.

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

Because the variable-pitch face is specified with "family = Sans Serif", 
and it is its only specification.  Specifying a font family means leaving 
a lot of freedom to the program (in this case Emacs, but the same applies 
to a browser for example) to select the font it wants among those 
installed on the system.  And there is no reason whatsoever to not obey 
that specification, unless there are strong reasons not to obey it (e.g. 
there are no Sans Serif fonts installed on the system, or the ones that 
are installed do not cover the character sets we want to display).  Which 
is evidently not the case here: if we're after a "Sans Serif semi-bold" 
font, and there are "Sans Serif bold" fonts installed on the system, they 
are good candidates.

There are, on my system, no less than 166 fonts in the "Sans Serif" 
family.  It just happens that none of them explicitly supports the 'heavy' 
weight / has no explicit 'heavy' variant.  But that is not a sufficient 
reason to reject all those 166 fonts.  What Emacs should do, what others 
programs do, and what Emacs would do with the patch, is to select the best 
possible font among those 166 fonts.

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

I don't know what else I could say to convince you.