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

Previous Next

Package: emacs;

Reported by: Stefan Monnier <monnier <at> iro.umontreal.ca>

Date: Fri, 18 Nov 2022 04:58:01 UTC

Severity: normal

Found in version 29.0.50

Done: Gregory Heytings <gregory <at> heytings.org>

Bug is archived. No further changes may be made.

Full log


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

From: Gregory Heytings <gregory <at> heytings.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: monnier <at> iro.umontreal.ca, 59347 <at> debbugs.gnu.org
Subject: Re: bug#59347: 29.0.50; `:family` face setting ignored
Date: Sun, 20 Nov 2022 21:49:46 +0000
>>> Yes.  We need to make sure the scoring will not now sometimes prefer 
>>> the medium weight where the regular weight exists and is a better 
>>> match. Not only should it not reject a legitimate font, but also not 
>>> prefer another font due to this change.  IOW, the change should 
>>> ideally only affect the cases where the 'medium' weight doesn't exist, 
>>> and we therefore prefer to use 'regular' rather than reject the 
>>> family.
>>
>> I don't think the case you have in mind could happen in the scenario of 
>> this bug or bug#57555 (if a regular weight exists and is a better match 
>> the loop in font_find_for_lface will exit with that better match), but 
>> indeed with some other call sequence this could perhaps happen.  I'll 
>> see what I can do.
>
> Thanks, it's indeed the other cases that I worry about.  We had a lot of 
> changes in this area which solved one problem only to create others.
>

After looking at this a bit closer, I don't see how font_score could be 
changed, or even why it should be changed.  It has only two callers: 
font_match_p and font_sort_entities.  The former only checks whether its 
return value is > 0 (IOW it only checks whether the font is an exact match 
or not).  The latter has only two callers: list-font and 
font_select_entity.  The latter has only one caller: font_find_for_lface. 
So it seems to me that there are no execution paths that could be 
negatively affected by this change (which is in font_find_for_lface).

Also, AFAIU, a font whose weight == spec_prop[weight] is in principle 
preferred to a font whose weight != spec_prop[weight].  However, a font 
whose weight != spec_prop[weight] could in practice be preferred to a font 
whose weight == spec_prop[weight] when it is a better match according to 
the other sorting criteria (size and width, and possibly type and slant). 
How could (and why should) this be changed to make sure that the scoring 
will not sometimes prefer the medium weight when the regular weight 
exists?

I'm probably missing something, but what?




This bug report was last modified 2 years and 160 days ago.

Previous Next


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