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, 22 Nov 2022 19:44:27 +0200 Message-ID: <834juq28as.fsf@gnu.org> References: <83cz9j9zyu.fsf@gnu.org> <838rk77yfo.fsf@gnu.org> <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> <0d1ea3007f6995e84576@heytings.org> <83a64j11mi.fsf@gnu.org> <0d1ea3007f6630ad784f@heytings.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="28945"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 59347@debbugs.gnu.org, monnier@iro.umontreal.ca To: Gregory Heytings Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Nov 22 18:46:11 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 1oxXLV-0007EP-Ph for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 22 Nov 2022 18:46:10 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oxXL3-0000EN-Pz; Tue, 22 Nov 2022 12:45:41 -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 1oxXKs-0000DI-Tu for bug-gnu-emacs@gnu.org; Tue, 22 Nov 2022 12:45:36 -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 1oxXKR-0005Wb-H3 for bug-gnu-emacs@gnu.org; Tue, 22 Nov 2022 12:45:26 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oxXKR-0003eI-Bo for bug-gnu-emacs@gnu.org; Tue, 22 Nov 2022 12:45:03 -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, 22 Nov 2022 17:45:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 59347 X-GNU-PR-Package: emacs X-Debbugs-Original-Cc: bug-gnu-emacs@gnu.org, monnier@iro.umontreal.ca, 59347@debbugs.gnu.org Original-Received: via spool by 59347-submit@debbugs.gnu.org id=B59347.166913906313942 (code B ref 59347); Tue, 22 Nov 2022 17:45:03 +0000 Original-Received: (at 59347) by debbugs.gnu.org; 22 Nov 2022 17:44:23 +0000 Original-Received: from localhost ([127.0.0.1]:52468 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oxXJm-0003co-Cq for submit@debbugs.gnu.org; Tue, 22 Nov 2022 12:44:22 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:37544) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oxXJj-0003cN-QM for 59347@debbugs.gnu.org; Tue, 22 Nov 2022 12:44:20 -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 1oxXJd-0005HW-CK; Tue, 22 Nov 2022 12:44:13 -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=QFkebJpA7Xn/zp9TSlrbOMRl5i/wsorJ4n/PQu8P/Hs=; b=n+ogiqxogWNR AsaUe2qKz3qjWBigI6QjvBxj6DXJbAHH9nNtBEeRM08+eNw2ddy3HGAGZqks3U/RmWfkCkQB+LNTL OsTBqP79xMXiLthZMUrXyC/xYO4t+j+xBxghvj597eSQeKPfym7rUCRRmJhF4fwU8oGnrpVTms8l+ ahK16Hfnp7h4v20lHXob3NNv49UU1f4UABEK3o8w7ZvCU8a+9nkgGeCMXZKiGxEc/rPqmZGaneg6W 85zk5Z9YC4LVE7KLTYoIKgFhCP6fHmzmxtwY0OZQ6QljYftU48KaxaATNdGIBf+0sn55GRG4Nt7kF 3p8tWh5/v8lCCCfa4ohMeQ==; 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 1oxXJc-0001zP-SC; Tue, 22 Nov 2022 12:44:13 -0500 In-Reply-To: <0d1ea3007f6630ad784f@heytings.org> (message from Gregory Heytings on Tue, 22 Nov 2022 15:41:47 +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:248662 Archived-At: > Date: Tue, 22 Nov 2022 15:41:47 +0000 > From: Gregory Heytings > cc: monnier@iro.umontreal.ca, 59347@debbugs.gnu.org, bug-gnu-emacs@gnu.org > > No, it won't reject valid fonts (unless I misunderstand what you mean by > "valid font"). For example, when searching for a font in the monospace > family, all fonts in the monospace family are considered. If no such > fonts are found, Emacs tries again (see face-font-family-alternatives) and > considers all fonts in the courier family. If no such fonts are found, > Emacs tries again and considers all fonts in the fixed family. After > which Emacs gives up. I feel like we have no focus in this dispute, and no real understanding of the goal. So let me go back to your scenario and ask you: what exactly is the problem with the scenario that you described? A reminder: (set-face-attribute 'default nil :font "Source Code Pro" :weight 'ultra-heavy) ;; 1 (set-face-attribute 'default nil :font "Source Code Pro" :weight 'heavy) ;; 2 (set-face-attribute 'default nil :font "Source Code Pro" :weight 'ultra-bold) ;; 3 (set-face-attribute 'default nil :font "Source Code Pro" :weight 'bold) ;; 4 (set-face-attribute 'default nil :font "Source Code Pro" :weight 'semi-bold) ;; 5 (set-face-attribute 'default nil :font "Source Code Pro" :weight 'medium) ;; 6 (set-face-attribute 'default nil :font "Source Code Pro" :weight 'normal) ;; 7 (set-face-attribute 'default nil :font "Source Code Pro" :weight 'semi-light) ;; 8 (set-face-attribute 'default nil :font "Source Code Pro" :weight 'light) ;; 9 (set-face-attribute 'default nil :font "Source Code Pro" :weight 'ultra-light) ;; 10 (set-face-attribute 'default nil :font "Source Code Pro" :weight 'thin) ;; 11 (If you don't have the Source Code Pro font on your system, I'm sure you can find another font with more weight variants with which you will observe a similar effect.) With current master, the variable-pitch face is realized as follows: - with 1-3: -ADBO-Source Code Pro-black-normal-normal-*-29-*-*-*-m-0-iso10646-1, which is a monospace font - with 4: -PfEd-DejaVu Sans-bold-normal-normal-*-29-*-*-*-*-0-iso10646-1, which is a variable pitch font - with 5: -ADBO-Source Code Pro-semibold-normal-normal-*-29-*-*-*-m-0-iso10646-1, which is again a monospace font - with 6: -urw-nimbus sans l-regular-r-normal--29-210-100-100-p-158-iso8859-1, which is a variable pitch font but without anti-aliasing - with 7: -PfEd-DejaVu Sans-regular-normal-normal-*-29-*-*-*-*-0-iso10646-1, which is a variable pitch font - with 8-9: -ADBO-Source Code Pro-light-normal-normal-*-29-*-*-*-m-0-iso10646-1, which is again a monospace font - with 10-11: -PfEd-DejaVu Sans-ultralight-normal-normal-*-29-*-*-*-*-0-iso10646-1, which is a variable pitch font Is the problem that you expected the family to be DejaVu Sans, but you got a different family in some cases? Or is the problem that you expected a variable-pitch font, but got a monospaced font in some cases? Or is the problem something else? And why is this result: - with 1-5: -PfEd-DejaVu Sans-bold-normal-normal-*-29-*-*-*-*-0-iso10646-1 - with 6-7: -PfEd-DejaVu Sans-regular-normal-normal-*-29-*-*-*-*-0-iso10646-1 - with 8-11: -PfEd-DejaVu Sans-ultralight-normal-normal-*-29-*-*-*-*-0-iso10646-1 better? You asked for ultra-heavy and heavy weight, but got bold -- why is that TRT? what if it really mattered to you to have several fonts of different heaviness? You also mentioned this: > Nothing tells it to reject fixed-pitch fonts as a last resort indeed. > But clearly the code should not select a fixed-pitch font _because_ it is > the only available font that supports say a 'semi-bold' weight, when > variable pitch fonts that support a 'bold' weight are in fact available. Why is it "clear" that font selection should do what you expect here, given that the only (weak) indication that we are after a variable-pitch font is the family? Why do you consider it so preposterous that Emacs comes up with a semi-bold font, when you ask for a semi-bold font? > Of course the weight of the default face should influence the weight of > all other faces. But not to the point that a 'bold' variable pitch font > is never even considered as a potential candidate for the variable-pitch > face. How do you know it wasn't considered? Maybe it was considered, but "lost" to what Emacs decided to be a better candidate? And again, there's no information of any kind in the font-spec we use that we are looking for a variable-pitch font. We only have the family. Given that no font in the family matches the specified width, why shouldn't Emacs try to find a font from another family that does match the width? > It's not that it doesn't produce satisfactory results, it's that it > doesn't do what it is meant to do. The scoring mechanism for the > weight/slant/width attributes is simply bypassed. Without unsetting these > three attributes, font_list_entities only produces candidates that are > exact matches (e.g. only "bold" fonts are returned), and the whole point > of scoring ("when searching for a semi-bold font, bold is better than > medium and worse than extra-bold") is entirely lost. The fact that we bypass scoring and look only for exact matches might be a valid criticism of the existing font-selection algorithm, but it doesn't yet tell us what should be the alternative. To decide what would be such an alternative, we need a good understanding of the goals of the font search in the various use cases we need to support. Which is why I'm asking all those questions. > My patch simply restores the scoring mechanism (and fixes at least three > bugs: 37473, 57555 and 59347). Unfortunately, I've seen too many changes in this area which solved a couple of problems, only to produce others, which took us time to discover. The last thing I want here is to do the same for the N+1st time. So let's first try to determine what exactly do we want to happen and why. Thanks.