From: Gregory Heytings <gregory@heytings.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: monnier@iro.umontreal.ca, 59347@debbugs.gnu.org
Subject: bug#59347: 29.0.50; `:family` face setting ignored
Date: Wed, 07 Dec 2022 11:00:24 +0000 [thread overview]
Message-ID: <a3e8923c0294f2856692@heytings.org> (raw)
In-Reply-To: <83k0347gtu.fsf@gnu.org>
>
> I will note right here that Emacs has no way of knowing whether the
> fonts returned by the font driver are or aren't variable-pitch. In
> fact, AFAIR it is a tricky and not very reliable to try deducing that
> from the font data Emacs records about each font (see 'font-info'). We
> just blindly trust the font driver to give us the appropriate list of
> fonts. IOW, for Emacs the family is just a meaningless string.
>
Indeed, Emacs trusts the font driver
>> If the specification passed to font_list_entities contains a non-nil
>> width, weight or slant, that list is immediately filtered and all fonts
>> that do not match these width, weight or slant exactly are removed from
>> the list.
>
> And you are saying that this filtering is wrong, yes?
>
No, that filtering in font_list_entities is not wrong, because
font_list_entities has another caller besides font_find_for_lface:
Flist_fonts. What is wrong is to call font_list_entities with these
attributes non-nil in
>>> why do you consider the family attribute of a face be more important
>>> than other attributes? if not all the attributes of a spec are "equal"
>>> in their importance, which attributes are more important, and why?
>>
>> Indeed, the attributes are not equal, in fact none of the attributes are
>> ever equal in their importance. The family is the most important one,
>> followed by the foundry, the registry, the additional style (in that
>> order, see the loop at the end of font_find_for_lface in which Emacs tries
>> to make each of these attributes less specific in turn, starting with the
>> least important one, namely the additional style), followed by the width,
>> height (or size), weight, slant (in the order specified by the variable
>> face-font-selection-order).
>
> That is not the relative importance of interest in the context of this
> discussion, because Emacs already does look for a suitable font in the order
> of the importance you describe.
>
> 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?
>
> And another question: if we are to follow face-font-selection-order, to
> observe the relative importance of the attributes as set by the user, then
> why did your patch only consider relaxing the weight (which is in the
> penultimate place in the order of importance), and not the slant (which is
> the least important attribute, in the default order we use)?
>
>> It is also in that loop (at the end of font_find_for_lface) that
>> face-font-family-alternatives are used. If the generic "Sans Serif",
>> "Monospace" and "Monospace Serif" families that Emacs uses are not a
>> recognized by the font driver (IOW, if font_list_entities returns an empty
>> result for these families), Emacs falls back to some hard-coded, less
>> generic, family names.
>
> I'm not sure I agree with this part of your description. The code looks up
> face-font-family-alternatives _before_ the loop in font_find_for_lface,
> i.e., _before_ font_list_entities is called. Where exactly do you see what
> you describe above?
>
>>> and if bold is fine when semi-bold was requested, what about other
>>> weights, like ultra-light -- are they also okay? if not, why not?
>>
>> Yes, ultra-light is also okay. If a program requests a font in the Sans
>> Serif family with a semi-bold weight, and the only available font on a
>> given system in that family is a ultra-light one, it's the best possible
>> match for that font specification. It's up to the user to install a font
>> in the Sans Serif family which has a semi-bold variant on their system, if
>> they need a font in the Sans Serif family with a semi-bold variant (or to
>> install another font that is closer to semi-bold than ultra-light, e.g.
>> one with a bold variant).
>>
>>>
>>> what are the criteria here and with other similar attributes?
>>>
>>
>> The family, foundry, registry and additional style attributes are passed
>> "as is" to the font driver, which returns a list of fonts matching these
>> attributes. The width, weight and/or slant are converted to numerical
>> values (with font-{width,weight,slant}-table), and font_score, called by
>> font_sort_entities, called by font_select_entity, which is applied on the
>> list of fonts returned by font_list_entities, selects the best match in
>> that list (according the the preferences in face-font-selection-order).
>> If the width, weight and/or slant were already passed to
>> font_list_entities, the list of fonts passed to font_select_entity
>> contains only fonts that match these width, weight and/or slant, and that
>> mechanism is bypassed.
>
> IOW, you want to disable the filtering of candidate fonts in
> font_list_entities, and instead consider _all_ the candidates, selecting the
> best match for the numerical attributes: width, height, weight, and slant.
> And you don't want to relax the non-numerical attributes (family, foundry,
> registry, adstyle) unless there's really no font, of any
> width/height/weight/slant, installed for the specified
> family/foundry/registry/adstyle. Is that right?
>
> If that is what you want us to do, then I must ask at least about the
> height: is it really reasonable to prefer _any_ height from the given
> family, even if it's radically different from what was requested?
>
> Also, the patch you suggested to install in
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=59347#77 doesn't do the above,
> it is basically a minor semi-kludgey change of the existing code, which only
> considers 'normal' weight when 'medium' was requested. Why didn't you
> submit a patch that follows your description and your critique to the
> logical conclusion?
>
> The rest of what I write below is based on the assumption that my
> understanding of your critique of the current code is as I describe above;
> if it is wrong, please ignore what's below, and please help me understand
> what is it that you are actually proposing and I misunderstood.
>
> So I see the following issues with your proposal (which AFAIU is different
> from the patch you actually posted):
>
> . we will examine much more fonts than we do now: the current code only
> examines matching fonts and returns the first one that satisfies the
> spec; your proposal will require us to examine all of them, in order to
> find the best match out of many
> . your logic, which says that the family is so much more important than the
> other attributes is not necessarily correct in all the cases where this
> code is executed: I can easily imagine cases where the requested weight
> is so important that no other "close" weight will do, and the caller
> really wants to get an empty list rather than a deviant font
>
> So I can only agree to installing the patch along the lines of the above
> logic, i.e. to make the code relax the numerical attributes trying to keep
> the family, on the following conditions:
>
> . we add an additional loop, like the one in font_find_for_lface, after the
> original one, and in that additional loop implement the examination of
> candidates without filtering then by numerical attributes up front; that
> additional loop will run only if the one before it came up with no fonts
> that match the family
> . whether the additional loop will actually run should be controlled by a
> variable exposed to Lisp, so that if this change causes regressions, we
> could easily find out this is the reason, and users could work around the
> regressions without rebuilding Emacs
>
> OK? And note that my agreement is not to the patch you posted, but to a
> more general change in the logic of examining the candidate fonts. This is
> how I understand what you think Emacs should do; if I misunderstood, please
> correct me.
>
> Thanks.
>
>
>
>
next prev parent reply other threads:[~2022-12-07 11:00 UTC|newest]
Thread overview: 123+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-18 4:57 bug#59347: 29.0.50; `:family` face setting ignored Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-11-18 12:37 ` Eli Zaretskii
2022-11-18 14:59 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-11-18 15:13 ` Eli Zaretskii
2022-11-18 15:25 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-11-18 16:54 ` Eli Zaretskii
2022-11-18 17:21 ` Eli Zaretskii
2022-11-18 20:00 ` Yuan Fu
2022-11-18 20:12 ` Yuan Fu
2022-11-18 21:09 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-11-19 7:21 ` Eli Zaretskii
2022-11-18 19:46 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-11-18 19:58 ` Eli Zaretskii
2022-11-18 20:55 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-11-19 7:15 ` Eli Zaretskii
2022-11-19 14:55 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-11-19 15:31 ` Eli Zaretskii
2022-11-19 16:01 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-11-19 16:16 ` Eli Zaretskii
2022-11-20 13:57 ` Gregory Heytings
2022-11-20 14:59 ` Eli Zaretskii
2022-11-20 15:35 ` Gregory Heytings
2022-11-20 15:54 ` Eli Zaretskii
2022-11-20 16:59 ` Gregory Heytings
2022-11-20 17:29 ` Eli Zaretskii
2022-11-20 17:43 ` Gregory Heytings
2022-11-20 17:58 ` Eli Zaretskii
2022-11-20 18:11 ` Gregory Heytings
2022-11-20 18:19 ` Eli Zaretskii
2022-11-20 19:45 ` Gregory Heytings
2022-11-20 20:01 ` Eli Zaretskii
2022-11-20 20:08 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-11-20 20:45 ` Gregory Heytings
2022-11-21 12:27 ` Eli Zaretskii
2022-11-20 18:30 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-11-20 18:53 ` Eli Zaretskii
2022-11-20 18:31 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-11-20 18:54 ` Eli Zaretskii
2022-11-20 21:49 ` Gregory Heytings
2022-11-21 12:51 ` Eli Zaretskii
2022-11-21 14:48 ` Gregory Heytings
2022-11-21 15:08 ` Eli Zaretskii
2022-11-21 23:34 ` Gregory Heytings
2022-11-22 0:34 ` Gregory Heytings
2022-11-22 3:05 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-11-22 7:59 ` Gregory Heytings
2022-11-22 13:38 ` Eli Zaretskii
2022-11-22 13:46 ` Gregory Heytings
2022-11-22 13:16 ` Eli Zaretskii
2022-11-22 13:38 ` Gregory Heytings
2022-11-22 14:38 ` Eli Zaretskii
2022-11-22 14:45 ` Gregory Heytings
2022-11-22 14:53 ` Eli Zaretskii
2022-11-22 15:41 ` Gregory Heytings
2022-11-22 17:44 ` Eli Zaretskii
2022-11-22 20:52 ` Gregory Heytings
2022-11-22 20:47 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-11-23 8:13 ` Gregory Heytings
2022-11-30 10:03 ` Gregory Heytings
2022-11-30 14:00 ` Eli Zaretskii
2022-11-30 15:38 ` Gregory Heytings
2022-12-04 14:21 ` Eli Zaretskii
2022-12-05 23:30 ` Gregory Heytings
2022-12-06 14:22 ` Eli Zaretskii
2022-12-07 11:00 ` Gregory Heytings [this message]
[not found] ` <d99c6016-3b32-1116-9ef1-43fe40a71a4@heytings.org>
2022-12-07 11:02 ` Gregory Heytings
2022-12-07 23:19 ` Gregory Heytings
2022-12-08 0:27 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-12-08 1:07 ` Gregory Heytings
2022-12-08 8:16 ` Eli Zaretskii
2022-12-08 14:59 ` Gregory Heytings
2022-12-08 15:13 ` Eli Zaretskii
[not found] ` <e1b79bb2-a3c5-2677-57d8-fb6db43dfd9@heytings.org>
2022-12-08 16:27 ` Gregory Heytings
2022-12-08 14:12 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-12-08 15:33 ` Gregory Heytings
2022-12-08 17:29 ` Drew Adams
2022-12-08 17:44 ` Eli Zaretskii
2022-12-08 5:32 ` Yuan Fu
2022-12-08 8:09 ` Eli Zaretskii
2022-12-08 14:17 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-12-08 14:49 ` Eli Zaretskii
2022-12-08 15:24 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-12-08 15:45 ` Eli Zaretskii
2022-12-08 8:03 ` Eli Zaretskii
2022-12-08 12:53 ` Gregory Heytings
2022-12-08 14:16 ` Eli Zaretskii
2022-12-08 15:17 ` Gregory Heytings
2022-12-08 15:42 ` Eli Zaretskii
2022-12-10 22:51 ` Gregory Heytings
2022-12-12 0:57 ` Gregory Heytings
2022-12-12 1:49 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-12-12 8:54 ` Gregory Heytings
2022-12-12 10:33 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-12-12 10:51 ` Gregory Heytings
2022-12-12 11:18 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-12-12 11:38 ` Gregory Heytings
2022-12-12 12:47 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-12-12 15:30 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-12-12 15:45 ` Eli Zaretskii
2022-12-12 15:07 ` Eli Zaretskii
2022-12-12 16:12 ` Gregory Heytings
2022-12-12 17:10 ` Eli Zaretskii
2022-12-12 21:28 ` Gregory Heytings
2022-12-13 11:58 ` Eli Zaretskii
2022-12-13 1:16 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-12-13 15:40 ` Eli Zaretskii
2022-12-04 14:23 ` Eli Zaretskii
2022-11-22 6:42 ` Gregory Heytings
2022-11-22 8:01 ` Gregory Heytings
2022-11-22 13:27 ` Eli Zaretskii
2022-11-22 12:38 ` Eli Zaretskii
2022-11-22 12:43 ` Gregory Heytings
2022-11-22 14:29 ` Eli Zaretskii
2022-11-22 14:39 ` Gregory Heytings
2022-11-22 14:52 ` Eli Zaretskii
2022-11-22 15:17 ` Gregory Heytings
2022-11-20 18:16 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-11-20 19:46 ` Gregory Heytings
2022-11-19 0:20 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-11-19 0:28 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-11-19 4:37 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-11-19 6:01 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-11-19 14:17 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a3e8923c0294f2856692@heytings.org \
--to=gregory@heytings.org \
--cc=59347@debbugs.gnu.org \
--cc=eliz@gnu.org \
--cc=monnier@iro.umontreal.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).