From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Gregory Heytings Newsgroups: gmane.emacs.bugs Subject: bug#59347: 29.0.50; `:family` face setting ignored Date: Wed, 07 Dec 2022 11:00:24 +0000 Message-ID: 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> <83k0347gtu.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25807"; mail-complaints-to="usenet@ciao.gmane.io" Cc: monnier@iro.umontreal.ca, 59347@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Dec 07 12:01:16 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 1p2sAt-0006TE-Ni for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 07 Dec 2022 12:01:15 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p2sAi-0001dr-JV; Wed, 07 Dec 2022 06:01:04 -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 1p2sAh-0001bX-28 for bug-gnu-emacs@gnu.org; Wed, 07 Dec 2022 06:01:03 -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 1p2sAg-0002ZH-8p for bug-gnu-emacs@gnu.org; Wed, 07 Dec 2022 06:01:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1p2sAg-0002bI-4L for bug-gnu-emacs@gnu.org; Wed, 07 Dec 2022 06:01:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Gregory Heytings Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 07 Dec 2022 11:01:02 +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.16704108299979 (code B ref 59347); Wed, 07 Dec 2022 11:01:02 +0000 Original-Received: (at 59347) by debbugs.gnu.org; 7 Dec 2022 11:00:29 +0000 Original-Received: from localhost ([127.0.0.1]:49576 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p2sA9-0002at-4g for submit@debbugs.gnu.org; Wed, 07 Dec 2022 06:00:29 -0500 Original-Received: from heytings.org ([95.142.160.155]:47328) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p2sA6-0002an-Oa for 59347@debbugs.gnu.org; Wed, 07 Dec 2022 06:00:27 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20220101; t=1670410825; bh=qmbgWv34vK0XD0/KarGSCLIdoej6eY1vUfNjpBOwkKE=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=EYi62pOzzEOAPib4/E7mhTgGjoOKhmdb4t2mbtUwzMrQNDfSnnD5+Q97nbW3+DXtd 8+0lktmJXTiC2QEtW0OBnFRQy1xZb7V9nvIYrGhy0ZKzJ+iclVmeQZ3eB8+3sgC07Z /o/gWsoIf+TdYdzVfjNnjzqRNmKUXqXnGL4ZeiVHB1QCfijZHIi9TR9UxMOQH52yUM zWVpo7AwlFjnKEjx8c1VyES7xgy+DFBinOCIf1gyCF77Y1mAbDUCnanvSSgvXlGiT7 +fkXSH/1delSM8pBEVAfLFEHbVtVQZ/3brTeDYlStqUeJ4v2ucdabeXueO9iNRMlYt BFZ474wTAJNng== In-Reply-To: <83k0347gtu.fsf@gnu.org> 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:250178 Archived-At: > > 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. > > > >