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

Previous Next

Full log

View this message in rfc822 format

From: Yuan Fu <casouri <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Gregory Heytings <gregory <at> heytings.org>, Eli Zaretskii <eliz <at> gnu.org>, 59347 <at> debbugs.gnu.org
Subject: bug#59347: 29.0.50; `:family` face setting ignored
Date: Wed, 7 Dec 2022 21:32:48 -0800

> On Dec 7, 2022, at 4:27 PM, Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors <bug-gnu-emacs <at> gnu.org> wrote:
> 
>>> My question was not about this basic relative importance, it was about
>>> something else: when none of the fonts of the given FAMILY fits the font
>>> spec, why do you consider keeping the family to be more important than
>>> keeping the weight?
>> I don't understand your question.  If we agree that there is an order of
>> importance in the attributes of a font spec,
> 
> Why should we agree on that?
> 
> When I specify the `:family` property on the `variable-pitch` face,
> I definitely want it to take precedence over the `:weight` of the
> default face, yes.
> 
> But when I specify the `weight` property of the `bold` face, it's not
> clear at all that the `:family` of the default face should take precedence
> over the `:weight` of the `bold` face.
> 
> FWIW, I've been running with your patch and I like the result.  I think
> it's better overall, but I suspect that we still have a fundamental
> problem with this notion of precedence/ordering.
> 
> Maybe the ordering should depend on the "stacking order" of the faces
> and their properties.  I.e. instead of merging `bold+variable-pitch+default` to get
> a set of properties on which we apply a globally-imposed ordering, we
> could keep track of the relative ordering of the properties: `bold` was
> on top, so the `:weight` property comes first, then came
> `variable-pitch` so its `:family` property comes second and the second
> comes afterwards.
> 
> So `bold+variable-pitch+default` could result in a different font than
> `variable-pitch+bold+default` even if the combined properties (i.e. the
> merged face) are identical.

IIUC currently all faces are realized into a “realized face”, where each attribute is filled in with parent faces’ attributes. So there is no difference between an explicitly assigned attribute and an inherited attribute at the time when Emacs selects fonts. But if I assign only :family attribute to a face, and that face inherits a :weight attribute, naturally the :family face should take precedence when selecting fonts. OTOH if I explicitly assign a :weight attribute, and the :family attribute is inherited, then :weight should probably take precedence.

IIUC you are just describing a generalized version of this strategy, right? I think it’s a good idea. Even if we don’t generalize it into a “stacking order”, but only record what’s inherited and what’s assigned explicitly, and prioritize the explicitly assigned attributes, it would produce more intuitive results, I think.

Yuan

Previous Next

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