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: Thu, 08 Dec 2022 01:07:25 +0000 Message-ID: References: <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="16323"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , 59347@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Dec 08 02:08:24 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 1p35Og-00044k-Ud for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 08 Dec 2022 02:08:22 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p35OO-0004gB-Mg; Wed, 07 Dec 2022 20:08: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 1p35OM-0004fx-Pn for bug-gnu-emacs@gnu.org; Wed, 07 Dec 2022 20:08: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 1p35OM-0007nq-Hz for bug-gnu-emacs@gnu.org; Wed, 07 Dec 2022 20:08:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1p35OM-0007jm-74 for bug-gnu-emacs@gnu.org; Wed, 07 Dec 2022 20:08: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: Thu, 08 Dec 2022 01:08: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.167046165129732 (code B ref 59347); Thu, 08 Dec 2022 01:08:02 +0000 Original-Received: (at 59347) by debbugs.gnu.org; 8 Dec 2022 01:07:31 +0000 Original-Received: from localhost ([127.0.0.1]:53303 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p35Nq-0007jU-Ok for submit@debbugs.gnu.org; Wed, 07 Dec 2022 20:07:31 -0500 Original-Received: from heytings.org ([95.142.160.155]:48154) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p35No-0007jO-2J for 59347@debbugs.gnu.org; Wed, 07 Dec 2022 20:07:29 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20220101; t=1670461646; bh=i0qqjF3oX4HJQMENeSOgP/P8YrENgQdEBoEVTmyfThE=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=lmQ/lPLsHYnyi3JajomSF39eWHd4/78VewQ2EIAc+uXSKArznACaGl+d8gvPv98yB xy4JuDI9tIemmDfyQK9RDCdlxg9pTJrl3dA9cL/9SWvaSNEMKxzmJAJYVRJEzijRv5 fC1tqfSxIRs1B3hZOC8j69gRN0hK/GpG0QNKD4QpTLDJjswA1faLsQ+mrqbb8Q5rLR +9WkQrCF2+iXz+thLnMMbWsxV36LueFOUhsjbEPwbSf5xapqPXuBciHkLyeZ/VmC1+ gjhkFyWWNg2Bcp2Rpq9aZzERcsFffsbTBm2Ehq3GblfEs2yeXthBZc4Lt1eIfSDlon /6e4ocY9EG3lw== In-Reply-To: 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:250234 Archived-At: > > But when I specify the `weight` property of the `bold` face, it's not > clear at all that the `:family` of the default face should take > precedence over the `:weight` of the `bold` face. > I'm not sure I understand what you mean. Do you mean that if a user chooses a font for the default face that has a single variant (say 'regular'), then the 'bold' face (which does not specify any family) should be realized with another font which has a bold variant? And that the 'italic' face should likewise be realized with another font which has an italic variant? Or do you mean that if a user chooses a font for the default face, and then updates the weight attribute of the 'bold' face to a weight value that is not explicitly supported by the font of the default face (say 'ultra-bold'), then the 'bold' face should be realized with another font that explicitly supports that variant? Or do you mean something else? FWIW, I don't think either of these options are reasonable. IMO in the first case the user should just use a font which has more variants for the default face (there are plenty of excellent fonts), and in the second case it is fine to approximate the weight with the weights that are available in the default font. > > Maybe the ordering should depend on the "stacking order" of the faces > and their properties. I.e. instead of merging > `bold+variable-pitch+default` to get a set of properties on which we > apply a globally-imposed ordering, we could keep track of the relative > ordering of the properties: `bold` was on top, so the `:weight` property > comes first, then came `variable-pitch` so its `:family` property comes > second and the second comes afterwards. > > So `bold+variable-pitch+default` could result in a different font than > `variable-pitch+bold+default` even if the combined properties (i.e. the > merged face) are identical. > Why not. But it is already possible to fine-tune each individual face with the existing mechanisms, so I'm not sure the added complexity is worth the price.