From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#59347: 29.0.50; `:family` face setting ignored Date: Tue, 06 Dec 2022 16:22:05 +0200 Message-ID: <83k0347gtu.fsf@gnu.org> References: <834juu9aya.fsf@gnu.org> <7cc9e03786024fc72f3b@heytings.org> <83a64l65ai.fsf@gnu.org> <7cc9e0378678a092e6ee@heytings.org> <835yf962q4.fsf@gnu.org> <7cc9e03786754c9e0aaf@heytings.org> <83zgcl4jra.fsf@gnu.org> <7cc9e03786c281cffdd4@heytings.org> <83tu2t4ie9.fsf@gnu.org> <7cc9e03786e324ff82ef@heytings.org> <83bkp04gjl.fsf@gnu.org> <83leo42vm9.fsf@gnu.org> <0d1ea3007fd94b7ae0b1@heytings.org> <83r0xv1649.fsf@gnu.org> <0d1ea3007f532a493429@heytings.org> <83cz9f12bh.fsf@gnu.org> <835yewleyn.fsf@gnu.org> <83tu2b9rlx.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="24095"; mail-complaints-to="usenet@ciao.gmane.io" Cc: monnier@iro.umontreal.ca, 59347@debbugs.gnu.org To: Gregory Heytings Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Dec 06 15:23:12 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1p2Yql-00063h-UH for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 06 Dec 2022 15:23:12 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p2Yqf-0004OL-4n; Tue, 06 Dec 2022 09:23:05 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p2Yqc-0004Ny-7B for bug-gnu-emacs@gnu.org; Tue, 06 Dec 2022 09:23:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1p2Yqb-0005pr-VN for bug-gnu-emacs@gnu.org; Tue, 06 Dec 2022 09:23:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1p2Yqb-0004NI-QJ for bug-gnu-emacs@gnu.org; Tue, 06 Dec 2022 09:23:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 06 Dec 2022 14:23:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 59347 X-GNU-PR-Package: emacs Original-Received: via spool by 59347-submit@debbugs.gnu.org id=B59347.167033655016804 (code B ref 59347); Tue, 06 Dec 2022 14:23:01 +0000 Original-Received: (at 59347) by debbugs.gnu.org; 6 Dec 2022 14:22:30 +0000 Original-Received: from localhost ([127.0.0.1]:43239 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p2Yq5-0004My-DV for submit@debbugs.gnu.org; Tue, 06 Dec 2022 09:22:30 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:44584) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p2Yq3-0004Ms-O8 for 59347@debbugs.gnu.org; Tue, 06 Dec 2022 09:22:28 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p2Ypy-0005gq-8P; Tue, 06 Dec 2022 09:22:22 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=UVaE/wbYkzy4DRmGEx8me6OQ7fkRsLrkwXXSQEYfjCs=; b=BnWprj7awC7C H0zjW5Kk69I69MwxZA21/AYT/AGKhvBtLHU34ozYSE5tpM+M/5uV1vCR6ToLvknH95UbIZgCqdF3S KYDCyhHFHKFFZqy/N3TNxZmhRLkN9orqS5qFw4M8MT94LHxVvFEYL5j00JGPZvLBuzJzSNPklV5hA jCpeaeRqoAvsQo+Q9nRD5I3TuL1cO2/rAoVsPHMOpLLLSFwGEC+iKITiDzkUe8b4D7uStwU0va1mU 0N60ucpu5sFC77JJ+0yATQYcgynp54OryphKd5g5nICMAQx3nvqOBVly2Fcy5dEQwPsLkGYub1xon WfAE3mnKiYZXbSQaau98nw==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p2Ypv-0003Bn-FE; Tue, 06 Dec 2022 09:22:21 -0500 In-Reply-To: (message from Gregory Heytings on Mon, 05 Dec 2022 23:30:48 +0000) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:250112 Archived-At: > Date: Mon, 05 Dec 2022 23:30:48 +0000 > From: Gregory Heytings > cc: monnier@iro.umontreal.ca, 59347@debbugs.gnu.org > > > I did not deserve such a public reprimand. I do not care at all about > being right or wrong personally, the only thing I care about here is > improving Emacs. I try to be as careful as possible, both in the code I > write and in the messages I post. In particular, I avoid posting anything > that is intentionally insulting, ironical, or even simply humorous. > > I already spent an unreasonable amount of time on this bug (I'd say easily > around 30 hours), although I have no personal interest in seeing it > resolved: I did not report it (or any of the bugs to which it is related), > and it does not and cannot affect me (I use the same fixed-pitch font > everywhere). > > Nonetheless, I'll try to answer your questions: Thank you. I hope we can now finish up dealing with this issue. > > where and how should Emacs get the indication that only variable-pitch > > fonts are acceptable in that case? > > It is not Emacs that decides which fonts correspond to a "family = Sans > Serif" specification, it is the font driver. In font_list_entities, Emacs > passes a font specification to a font driver, which returns a list of > fonts matching that specification. That is also what I know, so we agree on this point. 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. > 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? > > 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.