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 23:19:57 +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: multipart/mixed; boundary="axgqivedOD" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="23098"; 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 Thu Dec 08 00:21:20 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 1p33j5-0005rF-FJ for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 08 Dec 2022 00:21:19 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p33iq-0002KE-Ao; Wed, 07 Dec 2022 18:21: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 1p33io-0002Jm-VT for bug-gnu-emacs@gnu.org; Wed, 07 Dec 2022 18:21: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 1p33io-00058F-Ld for bug-gnu-emacs@gnu.org; Wed, 07 Dec 2022 18:21:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1p33io-0004Ub-7i for bug-gnu-emacs@gnu.org; Wed, 07 Dec 2022 18:21: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 23:21: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.167045520717232 (code B ref 59347); Wed, 07 Dec 2022 23:21:02 +0000 Original-Received: (at 59347) by debbugs.gnu.org; 7 Dec 2022 23:20:07 +0000 Original-Received: from localhost ([127.0.0.1]:52777 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p33hq-0004Tq-85 for submit@debbugs.gnu.org; Wed, 07 Dec 2022 18:20:07 -0500 Original-Received: from heytings.org ([95.142.160.155]:48048) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p33hn-0004TP-JC for 59347@debbugs.gnu.org; Wed, 07 Dec 2022 18:20:00 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20220101; t=1670455198; bh=4NZGzMB3TCi2EzgmCysKzO5ogj5oWyFHr4fTTxENglw=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=8wmbz0bVxvBUB9dtIB+glqy0d/aVc6CWyIJKS63MNYSVRFqD8TC2ON+Y12Yn7XMIe 87paq1+FeESy9DBQKZpCUCqDyb4OajCB3yfOHI2HTPWQXC/uVhTDa1uR0uxvtpcxOR oIYGZEpREPNtkXlwS4C+OBL/pJO5B3mT+PAYciQT0mkhOjKflGBUTgF0g1JBTk4p8t lkHX0vZHhQkHiUmHCPV9zpK1Hqg5yMkXKTgxBM5rNIbtoRWT5XDyRlNm399hXh3NhD pHfabQNBVJS4iarYgJNAnUSjCUfUV1EKHmOb4DUuUtblbip8uNu3+XNoc27uILz7LG iGivI4V16A/3A== 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:250226 Archived-At: --axgqivedOD Content-Type: text/plain; charset=us-ascii; format=flowed > > 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. > In a sense the family name is just a meaningless string indeed. The names "Serif", "Sans Serif" and "Monospace" are just a convention. And indeed, Emacs trusts the font driver, why wouldn't it? And what else could it do? The font driver itself calculates the "monospace" or "proportional" property based on the actual glyph widths in each font (at least that's what Fontconfig does). When all glyphs have the same width, the font is considered monospace and its 'spacing' property is set to 100. Otherwise the font is considered proportional and its 'spacing' property is set to 0. And if for some reason Fontconfig does not set that property correctly for a font, it can be forced by the user. I don't understand what you mean by "try deducing that from the font data Emacs records about each font". We could double-check that when we want a fixed-pitch font max-width == average-width == space-width, and when we want a variable-pitch font max-width != average-width != space-width, but what would be the benefit of doing that? >>> 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. > The problem is precisely that currently it doesn't do that, when faces such as variable-pitch are realized. The font list returned by font_list_entities called in font_find_for_lface (called by font_load_for_lface, called by realize_gui_face) is erroneously limited to fonts which have the exact same width/slant/weight attributes as the default face (which is _not_ the font that is being realized). If the default face has for example weight = medium, and Emacs realizes the variable-pitch face whose only non-nil attribute (in emacs -Q) is "family = Sans Serif", and if there are no fonts in the Sans Serif family with a weight equal to medium, font_list_entities returns an empty list. Which is wrong. > > 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? > I don't understand your question. If we agree that there is an order of importance in the attributes of a font spec, and that the family is the most important one, it seems clear to me that keeping the family is more important than keeping the weight. What am I missing? By the way, that's what Emacs already does, in most cases (the exception being the current bug). If (in emacs -Q) you (set-face-attribute 'variable-pitch nil :weight medium) and if (1) there are no fonts in the Sans Serif family with a medium weight on your system but (2) there are fonts in the Monospace family with a medium weight, Emacs will not suddenly select a fixed pitch font for the variable-pitch face. > > 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)? > That's not what the last patch I had sent did (see https://debbugs.gnu.org/cgi/bugreport.cgi?bug=59347#164). In that patch all these attributes (weight/slant/width) were set to nil. However, after spending a few more hours on this, I concluded that the fix I proposed in that patch was placed a bit too low in the abstraction layers, and that it is safer to place it where it belongs, namely in realize_gui_face. font_find_for_lface has other callers, which may depend in subtle ways on its current behavior. I attach that new, and hopefully final, patch. I checked in particular it with the recipes of bug#37473, bug#57555, bug#59347 and bug#59371, and with some variants. All seem to work correctly. >> 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? > The code in font_find_for_lface just above the final loop that looks up face-font-family-alternatives only populates the 'family' array. Nothing "concrete" happens in font_find_for_lface before the final loop: the code only populates the 'family', 'foundry', 'registry' and 'adstyle' arrays, as well as the 'work' font spec. >>> 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. > Yes, that's still what I want to do, but in realize_gui_face and not in font_find_for_lface anymore. > > 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. > It is not necessary to change anything there, because the loop at the end of font_find_for_lface already relaxes these non-numerical attributes when necessary: if there is no font of any width/height/weight/slant for the specified family/foundry/registry/adstyle, Emacs tries to set adstyle to nil (if it isn't already), then to set registry to nil (if it isn't already), then to set foundry to nil (if it isn't already). And if doing that had no effect, Emacs tries the alternative family names listed in face-font-family-alternatives. > > 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? > The height (or size) attribute already receives a special treatment in font_find_for_lface, where it is already set to nil before being passed to font_list_entities. --axgqivedOD Content-Type: text/x-diff; name=Unset-the-weight-slant-width-in-the-spec-when-realiz.patch Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: attachment; filename=Unset-the-weight-slant-width-in-the-spec-when-realiz.patch RnJvbSA0N2I0ZjA5Nzg2ZjFlZGZmMGE2NWE5YzUyZWI0ZjYyNjEyZjNmNWUz IE1vbiBTZXAgMTcgMDA6MDA6MDAgMjAwMQ0KRnJvbTogR3JlZ29yeSBIZXl0 aW5ncyA8Z3JlZ29yeUBoZXl0aW5ncy5vcmc+DQpEYXRlOiBXZWQsIDcgRGVj IDIwMjIgMjM6MTU6MDYgKzAwMDANClN1YmplY3Q6IFtQQVRDSF0gVW5zZXQg dGhlIHdlaWdodC9zbGFudC93aWR0aCBpbiB0aGUgc3BlYyB3aGVuIHJlYWxp emluZyBhDQogZm9udA0KDQpCZXR3ZWVuIGNvbW1pdHMgYmYwZDNmNzZkYyAo MjAxNCkgYW5kIDZiMWVkMmYyYzkgKDIwMjIpLA0KcmVhbGl6ZV9ndWlfZmFj ZSBjYWxsZWQgZm9udF9sb2FkX2Zvcl9sZmFjZSB3aXRoIGFuIGVtcHR5IG9y DQpwYXJ0bHkgZW1wdGllZCBmb250IHNwZWMsIGkuZS4gaXQgaWdub3JlZCBh IHBhcnQgb2YgaXRzIGF0dHJzDQphcmd1bWVudC4gIFRoZSByYXRpb25hbGUg Z2l2ZW4gaW4gYnVnIzE3OTczLCB3aGljaCBsZWQgdG8NCmJmMGQzZjc2ZGMs IGlzIG5vdCBjbGVhci4gIEhvd2V2ZXIsIDZiMWVkMmYyYzksIHdoaWNoIHBh c3Nlcw0KdGhlIGZ1bGwgZm9udCBzcGVjIHRvIGZvbnRfbG9hZF9mb3JfbGZh Y2UgYW5kDQpmb250X2ZpbmRfZm9yX2xmYWNlLCBsZWFkcyB0byBzdWJvcHRp bWFsIGZvbnQgY2hvaWNlcywgZm9yDQpleGFtcGxlIHdoZW4gdGhlIGZvbnQg Y2hvc2VuIGZvciB0aGUgZGVmYXVsdCBmYWNlIGhhcyBhDQp3ZWlnaHQsIHNs YW50IG9yIHdpZHRoIHRoYXQgaXMgbm90IHN1cHBvcnRlZCBieSBvdGhlcg0K YXZhaWxhYmxlIGZvbnRzIG9uIHRoZSBzeXN0ZW0sIHN1Y2ggYXMgJ21lZGl1 bScgb3IgJ2hlYXZ5Jy4NCg0KSWYgdGhlc2UgYXR0cmlidXRlcyBhcmUgbm90 IHVuc2V0IGhlcmUsIHRoZSBjYWxsIHRvDQpmb250X2xpc3RfZW50aXRpZXMg aW4gZm9udF9maW5kX2Zvcl9sZmFjZSBhcmJpdHJhcmlseSBsaW1pdHMNCnRo ZSBjYW5kaWRhdGUgZm9udCBsaXN0IHRvIHRob3NlIHRoYXQgYXJlIHBlcmZl Y3QgbWF0Y2hlcyBmb3INCnRoZXNlIGF0dHJpYnV0ZXMsIHdoaWNoIG1lYW5z IHRoYXQgdGhlIHNjb3JpbmcgbWVjaGFuaXNtIGlzDQpieXBhc3NlZC4gIE5v dGUgdGhhdCB0aGUgc2l6ZSBhdHRyaWJ1dGUgaW4gc3BlYyBpcyBhbHNvIHVu c2V0LA0KaW4gZm9udF9maW5kX2Zvcl9sZmFjZS4NCg0KKiBzcmMveGZhY2Vz LmMgKHJlYWxpemVfZ3VpX2ZhY2UpOiBVbnNldCB0aGUgd2VpZ2h0LCBzbGFu dCBhbmQNCndpZHRoIG9mIHRoZSBmb250IHNwZWMuICBGaXhlcyBidWcjNTc1 NTUgYW5kIGJ1ZyM1OTM0Ny4NCi0tLQ0KIHNyYy94ZmFjZXMuYyB8IDIwICsr KysrKysrKysrKysrKysrKy0tDQogMSBmaWxlIGNoYW5nZWQsIDE4IGluc2Vy dGlvbnMoKyksIDIgZGVsZXRpb25zKC0pDQoNCmRpZmYgLS1naXQgYS9zcmMv eGZhY2VzLmMgYi9zcmMveGZhY2VzLmMNCmluZGV4IGRmMDc4MjI3YzguLjcx MDQyYTMxMjYgMTAwNjQ0DQotLS0gYS9zcmMveGZhY2VzLmMNCisrKyBiL3Ny Yy94ZmFjZXMuYw0KQEAgLTYwNzEsOCArNjA3MSwyNCBAQCByZWFsaXplX2d1 aV9mYWNlIChzdHJ1Y3QgZmFjZV9jYWNoZSAqY2FjaGUsIExpc3BfT2JqZWN0 IGF0dHJzW0xGQUNFX1ZFQ1RPUl9TSVpFXQ0KIAkgICAgZW1hY3NfYWJvcnQg KCk7DQogCX0NCiAgICAgICBpZiAoISBGT05UX09CSkVDVF9QIChhdHRyc1tM RkFDRV9GT05UX0lOREVYXSkpDQotCWF0dHJzW0xGQUNFX0ZPTlRfSU5ERVhd DQotCSAgPSBmb250X2xvYWRfZm9yX2xmYWNlIChmLCBhdHRycywgYXR0cnNb TEZBQ0VfRk9OVF9JTkRFWF0pOw0KKwl7DQorCSAgTGlzcF9PYmplY3Qgc3Bl YyA9IGNvcHlfZm9udF9zcGVjIChhdHRyc1tMRkFDRV9GT05UX0lOREVYXSk7 DQorCSAgLyogVW5zZXQgdGhlIHdlaWdodCwgc2xhbnQgYW5kIHdpZHRoIGlu IHNwZWMuICBUaGUgYmVzdA0KKwkgICAgIHBvc3NpYmxlIHZhbHVlcyBmb3Ig dGhlc2UgYXR0cmlidXRlcyBpcyBkZXRlcm1pbmVkIGluDQorCSAgICAgZm9u dF9maW5kX2Zvcl9sZmFjZSwgY2FsbGVkIGJ5IGZvbnRfbG9hZF9mb3JfbGZh Y2UsIHdoZW4NCisJICAgICB0aGUgY2FuZGlkYXRlIGxpc3QgcmV0dXJuZWQg YnkgZm9udF9saXN0X2VudGl0aWVzIGlzDQorCSAgICAgc29ydGVkIGJ5IGZv bnRfc2VsZWN0X2VudGl0eSAod2hpY2ggY2FsbHMNCisJICAgICBmb250X3Nv cnRfZW50aXRpZXMsIHdoaWNoIGNhbGxzIGZvbnRfc2NvcmUpLiAgSWYgdGhl c2UNCisJICAgICBhdHRyaWJ1dGVzIGFyZSBub3QgdW5zZXQgaGVyZSwgdGhl IGNhbmRpZGF0ZSBmb250IGxpc3QNCisJICAgICByZXR1cm5lZCBieSBmb250 X2xpc3RfZW50aXRpZXMgb25seSBjb250YWlucyBmb250cyB0aGF0DQorCSAg ICAgYXJlIGV4YWN0IG1hdGNoZXMgZm9yIHRoZXNlIHdlaWdodCwgc2xhbnQg YW5kIHdpZHRoDQorCSAgICAgYXR0cmlidXRlcywgd2hpY2ggbGVhZHMgdG8g c3Vib3B0aW1hbCBvciB3cm9uZyBmb250DQorCSAgICAgY2hvaWNlcy4gIFNl ZSBidWcjNTkzNDcuICAqLw0KKwkgIEFTRVQgKHNwZWMsIEZPTlRfV0VJR0hU X0lOREVYLCBRbmlsKTsNCisJICBBU0VUIChzcGVjLCBGT05UX1NMQU5UX0lO REVYLCBRbmlsKTsNCisJICBBU0VUIChzcGVjLCBGT05UX1dJRFRIX0lOREVY LCBRbmlsKTsNCisJICBhdHRyc1tMRkFDRV9GT05UX0lOREVYXSA9IGZvbnRf bG9hZF9mb3JfbGZhY2UgKGYsIGF0dHJzLCBzcGVjKTsNCisJfQ0KICAgICAg IGlmIChGT05UX09CSkVDVF9QIChhdHRyc1tMRkFDRV9GT05UX0lOREVYXSkp DQogCXsNCiAJICBmYWNlLT5mb250ID0gWEZPTlRfT0JKRUNUIChhdHRyc1tM RkFDRV9GT05UX0lOREVYXSk7DQotLSANCjIuMzUuMQ0KDQo= --axgqivedOD--