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

[Gregory Heytings]

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

I'm not sure I understand what you mean.

Do you mean that if a user chooses a font for the default face that has a 
single variant (say 'regular'), then the 'bold' face (which does not 
specify any family) should be realized with another font which has a bold 
variant?  And that the 'italic' face should likewise be realized with 
another font which has an italic variant?

Or do you mean that if a user chooses a font for the default face, and 
then updates the weight attribute of the 'bold' face to a weight value 
that is not explicitly supported by the font of the default face (say 
'ultra-bold'), then the 'bold' face should be realized with another font 
that explicitly supports that variant?

Or do you mean something else?

FWIW, I don't think either of these options are reasonable.  IMO in the 
first case the user should just use a font which has more variants for the 
default face (there are plenty of excellent fonts), and in the second case 
it is fine to approximate the weight with the weights that are available 
in the default font.

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

Why not.  But it is already possible to fine-tune each individual face 
with the existing mechanisms, so I'm not sure the added complexity is 
worth the price.