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: Thu, 08 Dec 2022 10:03:36 +0200 Message-ID: <83v8mm2ug7.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> <83k0347gtu.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14626"; 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 Thu Dec 08 09:04:41 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 1p3BtZ-0003Vs-Du for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 08 Dec 2022 09:04:41 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p3BtM-0006mi-Ey; Thu, 08 Dec 2022 03:04:29 -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 1p3Bsw-0006kp-Pf for bug-gnu-emacs@gnu.org; Thu, 08 Dec 2022 03:04: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 1p3Bsw-0005QN-HV for bug-gnu-emacs@gnu.org; Thu, 08 Dec 2022 03:04:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1p3Bsv-0005Rh-Tj for bug-gnu-emacs@gnu.org; Thu, 08 Dec 2022 03:04: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: Thu, 08 Dec 2022 08:04: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.167048663720927 (code B ref 59347); Thu, 08 Dec 2022 08:04:01 +0000 Original-Received: (at 59347) by debbugs.gnu.org; 8 Dec 2022 08:03:57 +0000 Original-Received: from localhost ([127.0.0.1]:55128 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p3Bsr-0005RT-An for submit@debbugs.gnu.org; Thu, 08 Dec 2022 03:03:57 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:49912) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p3Bsp-0005RN-3H for 59347@debbugs.gnu.org; Thu, 08 Dec 2022 03:03:56 -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 1p3Bsh-0004jO-PD; Thu, 08 Dec 2022 03:03:49 -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=0kduKbTPsq9JdvtlNMVu/FbBMqPGpBh2drfRfqSNY8A=; b=VV3uZjc8jwIY TCLZHkmtgTwIG59Y2ml1g+b6HWny5t/irFgzOXIPOiNkfOplKPYn5ORJIEGoocTz0EdPsmioueUC5 UYCfVoE7gciQVgMFYXXqqdmSk+R+vQFYFGvWl2MzMMt71BrMJ/Om3qR+rh3qO0McSiUm5hAwWb4wW hZtXHKzSZjroWVdgsiS+UIleaPUrLszxULVKRLbt3AQMm3GFPcezJrFc3FrpZLC1dof9+zDgWE8ad G+rmyx7UjfTaZJwI5ulXEB5dGa6pTS/Z6K4BpE+cvJWT2692EnfwnowlmlN6dKblP7aaMC/Ilwf1K epLM9XR2f60Frj/omQV37Q==; 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 1p3Bsh-0006qV-84; Thu, 08 Dec 2022 03:03:47 -0500 In-Reply-To: (message from Gregory Heytings on Wed, 07 Dec 2022 23:19:57 +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:250247 Archived-At: > Date: Wed, 07 Dec 2022 23:19:57 +0000 > From: Gregory Heytings > cc: monnier@iro.umontreal.ca, 59347@debbugs.gnu.org > Thanks for the detailed response. I don't want to restart this long discussion from the beginning, so I will limit myself only to the a few comments, and try to focus on the patch you suggest. We don't need to agree about the rest. > 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? (The check you are suggesting above doesn't work reliably, IME.) My point was that _if_ we wanted to implement some logic in Emacs that a family implying variable-pitch fonts must yield only variable-pitch fonts (and similarly for fixed-pitch fonts), we'd need to have code for doing that, something that we don't have and AFAIR cannot be implemented for all the font backends we want to support. You don't suggest adding such a test, so we don't need to discuss this tangent. > > 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? The order on which we agreed is only about the numerical attributes: width, height, weight, and slant. I'm asking about the other attributes, and about their importance relative to the numerical ones. You seem to say that this order is self-evident, and I'm questioning that. But we don't need to keep arguing about this tangent, either. > 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. What about bug#51768, bug#52493, bug#52888, and the problem reported in https://lists.gnu.org/archive/html/emacs-devel/2021-12/msg01643.html? Also, did you test Emacs invocation as in "emacs -fn FONT" where FONT is specified as Fontconfig and XLFD patterns documented in the "Fonts" node of the Emacs user manual? E.g., what happens if you use the Fontconfig pattern such as "Sans Serif-12:weight=black:slant=oblique:width=condensed"? -- does Emacs start with a font with the expected attributes, both when such a font which matches exactly exists and when an exact match doesn't exist? I'm asking this because AFAIR realize_gui_face is called at startup for the default face of the initial frame, and we need to make sure your proposed patch works in that case as well, even though it basically throws away the weight, slant, and width attributes that were requested. > diff --git a/src/xfaces.c b/src/xfaces.c > index df078227c8..71042a3126 100644 > --- a/src/xfaces.c > +++ b/src/xfaces.c > @@ -6071,8 +6071,24 @@ realize_gui_face (struct face_cache *cache, Lisp_Object attrs[LFACE_VECTOR_SIZE] > emacs_abort (); > } > if (! FONT_OBJECT_P (attrs[LFACE_FONT_INDEX])) > - attrs[LFACE_FONT_INDEX] > - = font_load_for_lface (f, attrs, attrs[LFACE_FONT_INDEX]); > + { > + Lisp_Object spec = copy_font_spec (attrs[LFACE_FONT_INDEX]); > + /* Unset the weight, slant and width in spec. The best > + possible values for these attributes is determined in > + font_find_for_lface, called by font_load_for_lface, when > + the candidate list returned by font_list_entities is > + sorted by font_select_entity (which calls > + font_sort_entities, which calls font_score). If these > + attributes are not unset here, the candidate font list > + returned by font_list_entities only contains fonts that > + are exact matches for these weight, slant and width > + attributes, which leads to suboptimal or wrong font > + choices. See bug#59347. */ > + ASET (spec, FONT_WEIGHT_INDEX, Qnil); > + ASET (spec, FONT_SLANT_INDEX, Qnil); > + ASET (spec, FONT_WIDTH_INDEX, Qnil); > + attrs[LFACE_FONT_INDEX] = font_load_for_lface (f, attrs, spec); > + } > if (FONT_OBJECT_P (attrs[LFACE_FONT_INDEX])) > { > face->font = XFONT_OBJECT (attrs[LFACE_FONT_INDEX]); As I mentioned earlier, any such change must be controlled by a variable exposed to Lisp, which could then be used to investigate and perhaps countermand any regressions it could cause. If you agree to adding such a variable, I'm okay with installing this on the emacs-29 branch.