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: Gregory Heytings <gregory <at> heytings.org>
Cc: monnier <at> iro.umontreal.ca, 59347 <at> debbugs.gnu.org
Subject: bug#59347: 29.0.50; `:family` face setting ignored
Date: Tue, 22 Nov 2022 16:38:58 +0200

> Date: Tue, 22 Nov 2022 13:38:19 +0000
> From: Gregory Heytings <gregory <at> heytings.org>
> cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, 59347 <at> debbugs.gnu.org
> 
> > Whereas with your proposal, it will start from a "clean slate" every 
> > time and will need to examine many (if not all) of the fonts on the 
> > system to be sure score-only matches will find the best candidate.
> >
> 
> That's not what it does, no.  The loop in font_find_for_lface limits the 
> number of fonts that are considered to some foundry, family, registry and 
> additional style, and only considers more fonts if no suitable fonts have 
> been found.

But the same considerations apply to weight, slant, and width: shouldn't we
prefer an identical value for each one of those, if that is possible?
font_score has its own ideas about which one of these 3 is "more equal",
AFAICT.

And if no suitable candidate is found by making these 3 attributes free,
then we are back to the same problem, now with non-numerical attributes.
Right?

> > Also, font_score only scores the numerical attributes, so how do we 
> > assess the "score" of matches for :family or :adstyle?
> 
> That's the purpose of the loop at the end of font_find_for_lface.  It 
> starts with a specific spec and gradually makes it less specific if 
> necessary (that is, if no suitable font has been found with a more 
> specific spec).

So we will be back to the same problem with those.

Previous Next

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