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: Mon, 21 Nov 2022 14:48:59 +0000 Message-ID: References: <83bkp4bfqf.fsf@gnu.org> <83wn7s9txp.fsf@gnu.org> <83pmdk9pat.fsf@gnu.org> <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> 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="29363"; 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 Mon Nov 21 15:50:38 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 1ox885-0007K4-S4 for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 21 Nov 2022 15:50:37 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ox87a-0005Kx-7T; Mon, 21 Nov 2022 09:50:06 -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 1ox87W-0005Jm-Ty for bug-gnu-emacs@gnu.org; Mon, 21 Nov 2022 09:50: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 1ox87W-0007NS-KT for bug-gnu-emacs@gnu.org; Mon, 21 Nov 2022 09:50:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ox87W-0004zd-GG for bug-gnu-emacs@gnu.org; Mon, 21 Nov 2022 09:50: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: Mon, 21 Nov 2022 14:50: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.166904214319080 (code B ref 59347); Mon, 21 Nov 2022 14:50:02 +0000 Original-Received: (at 59347) by debbugs.gnu.org; 21 Nov 2022 14:49:03 +0000 Original-Received: from localhost ([127.0.0.1]:45990 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ox86Z-0004xe-9X for submit@debbugs.gnu.org; Mon, 21 Nov 2022 09:49:03 -0500 Original-Received: from heytings.org ([95.142.160.155]:53006) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ox86X-0004x7-AW for 59347@debbugs.gnu.org; Mon, 21 Nov 2022 09:49:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20220101; t=1669042139; bh=cjYdf2mIXMzaB7zcuDlQ+L57n+L+0NOuQTFWHRHSOo8=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=6ZSV4eX1kvHyHg84ClW8onUQn2jce/RWDpHvNgyTxEUTQzig3pNVLtR2juAn4h5SO KzDbZoEAK+JSAFGOfdAOHmMnit/MBwsJUMxZJ4AocbZo0XEFo7OjdWtcPj3smVQKk8 p/miFzgWyoQgUF0C8A3yZSKcg/neveGxuR1N1E21jAst3hr+qGBktt4Qv2Ytdod+mM sU9nbAiQc60oRgVGS/ZJNsUEb9bdsIJVw0urYAVB6/rsSaDBIusvyF+uVo1Ri5Lgtj 8I5Gvg7wQwO6sKuro/OAkWAd7Ln8C3c+z64nQxMBYFCR++gGej2Umv13oPG6HS/xBO dMHfTg+FkfpWg== In-Reply-To: <83bkp04gjl.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:248540 Archived-At: >> Also, AFAIU, a font whose weight == spec_prop[weight] is in principle >> preferred to a font whose weight != spec_prop[weight]. However, a font >> whose weight != spec_prop[weight] could in practice be preferred to a >> font whose weight == spec_prop[weight] when it is a better match >> according to the other sorting criteria (size and width, and possibly >> type and slant). How could (and why should) this be changed to make >> sure that the scoring will not sometimes prefer the medium weight when >> the regular weight exists? > > I thought the answer to your question would be "adjust the scoring such > that what we don't want to happen, doesn't". > > One way of doing that is by boosting the score when there's an exact > match in attributes which we consider "more equal than others". I guess > weight is one of them, and perhaps the only one. > Hmmm... AFAIU that's already the case: when there's an exact match (e.g. we're expecting a medium font and the font is medium) the weight field for that font is 0, and when there's an inexact match (e.g. we're expecting a medium font and the font is regular) we store the difference between the two weights (which is 20 in this case) in the weight field. It does not seem possible (at least not without adding a lot of complexity) inside font_score to know that the font only has a medium variant and that if we're expecting a regular font, we should therefore consider that the font is an exact (or "less inexact than if the font had a regular variant") match. And, even if we don't do that, in that case and similar ones a medium variant will be better scored than a semi-bold or semi-light one. All in all, it seems to me that we should not change font_score now. > > Btw, another conceptual issue I have with your patch is that it treats > 'medium' and 'regular' asymmetrically (AFAIU): if we see 'medium', we > also consider 'normal', but not vice versa. Why the asymmetry? why not > always consider the other when we see the one? > That's correct, indeed. The reason (which is perhaps not convincing enough?) is that fonts with an explicit 'medium' variant are less common than fonts with an explicit 'normal' variant. So if we're trying to find a 'normal' font, the likelihood that a 'medium' font would be a better match than a 'normal' font is low.