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

Previous Next

Full log

Message #263 received at 59347 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 59347 <at> debbugs.gnu.org
Subject: Re: bug#59347: 29.0.50; `:family` face setting ignored
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.

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.


        Stefan

Previous Next

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