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: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: gregory <at> heytings.org, 59347 <at> debbugs.gnu.org
Subject: bug#59347: 29.0.50; `:family` face setting ignored
Date: Thu, 08 Dec 2022 10:09:58 +0200

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  59347 <at> debbugs.gnu.org
> Date: Wed, 07 Dec 2022 19:27:28 -0500
> 
> >> 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.

If we want to distinguish between explicitly requested attributes and
inherited attributes, we need to store this information inside the
font spec.  (We have the :user-spec attribute, but it is used for
slightly different purposes.)

Please also note that explicit requests for attributes can come from a
Lisp program, not from the user.

> FWIW, I've been running with your patch and I like the result.

Which patch is that?  The one proposed in the message to which you are
responding, or one of the earlier ones?

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

How would you determine the order in the stack?  IOW, which attributes
will be "the first"?

Previous Next

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