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: Tue, 22 Nov 2022 20:52:42 +0000 Message-ID: <0d1ea3007f1d7523338e@heytings.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> <834juq28as.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="31705"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 59347@debbugs.gnu.org, monnier@iro.umontreal.ca To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Nov 22 21:54:03 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 1oxaHD-0007jY-V7 for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 22 Nov 2022 21:53:56 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oxaGQ-00038w-W5; Tue, 22 Nov 2022 15:53:07 -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 1oxaGP-00031N-4G for bug-gnu-emacs@gnu.org; Tue, 22 Nov 2022 15:53:05 -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 1oxaGN-00012H-4v for bug-gnu-emacs@gnu.org; Tue, 22 Nov 2022 15:53:04 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oxaGN-0004Qa-0B for bug-gnu-emacs@gnu.org; Tue, 22 Nov 2022 15:53:03 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Gregory Heytings Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 22 Nov 2022 20:53: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.166915036716983 (code B ref 59347); Tue, 22 Nov 2022 20:53:02 +0000 Original-Received: (at 59347) by debbugs.gnu.org; 22 Nov 2022 20:52:47 +0000 Original-Received: from localhost ([127.0.0.1]:52669 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oxaG6-0004Pq-JZ for submit@debbugs.gnu.org; Tue, 22 Nov 2022 15:52:47 -0500 Original-Received: from heytings.org ([95.142.160.155]:54984) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oxaG4-0004Ph-96 for 59347@debbugs.gnu.org; Tue, 22 Nov 2022 15:52:45 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20220101; t=1669150362; bh=/qnbZ7Z4X25W4GisVkd3Scwamjr2obi+FOsC6mZ4eyw=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=vq6MjaVWu0kfvTVrhP4GuNcsWRNZi67IUdctj/9QDTDD+bbGMVO2VKtrXhVQATHXN NEIQlvlMoXRFmfyt9Tqyo4UZY+vVwtFv2wWBjzWCLum0j4QXbeowpqKm3bPNs/P0zI ng82wmpchT6NgBSInFJ3IVjAUrtgk/JZtRsCpe9dpXHZZAFd5TqPjqz77xa7gwv9Xh HoDC3NyPYA6qQzg/plYc76EMzRMR2g4zOdYAXZUga+SMYgltELvl49HRwIOiO1Y1Lx BcRMDTAdb/sNv6fzTovVYeaPLCTiohn5YSAvKa+b+Ql7akWtLtxjKpvxZjK9ceiURZ vESCCVV7LtOJA== In-Reply-To: <834juq28as.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:248679 Archived-At: > > So let me go back to your scenario and ask you: what exactly is the > problem with the scenario that you described? A reminder: > > 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? > The problem is that users expect a variable pitch font for the variable-pitch face (and an antialiased font when antialising is on). That's what the "family = Sans Serif" specification of that face means. > > 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? > It is better because the "family = Sans Serif" specification of the variable-pitch face is obeyed. (Incidentally, that result corresponds to the result returned by fc-match for those weights.) > > You asked for ultra-heavy and heavy weight, but got bold -- why is that > TRT? > Same answer: it is TRT because the "family = Sans Serif" specification of the variable-pitch face is obeyed. >> 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? > You seem to misunderstand how font selection works. The "family = Sans Serif" specification of the variable-pitch face is not at at all a "weak" indication that we are after a variable pitch font, it's the strongest possible indication that we are after a variable pitch font. It means "please choose whatever font you want among those installed on the system, but one in the Sans Serif family", "Sans Serif" being one of the few generic font families. It's like the "Monospace" family for the default font. It would be wrong if Emacs decided to select a variable pitch font for the default face, wouldn't it? >> 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? > I debugged the code. > > 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. > See above. > > 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? > Because the variable-pitch face is specified with "family = Sans Serif", and it is its only specification. Specifying a font family means leaving a lot of freedom to the program (in this case Emacs, but the same applies to a browser for example) to select the font it wants among those installed on the system. And there is no reason whatsoever to not obey that specification, unless there are strong reasons not to obey it (e.g. there are no Sans Serif fonts installed on the system, or the ones that are installed do not cover the character sets we want to display). Which is evidently not the case here: if we're after a "Sans Serif semi-bold" font, and there are "Sans Serif bold" fonts installed on the system, they are good candidates. There are, on my system, no less than 166 fonts in the "Sans Serif" family. It just happens that none of them explicitly supports the 'heavy' weight / has no explicit 'heavy' variant. But that is not a sufficient reason to reject all those 166 fonts. What Emacs should do, what others programs do, and what Emacs would do with the patch, is to select the best possible font among those 166 fonts. > > 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. > I don't know what else I could say to convince you.