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#52888: 29.0.50; font_{delete_unmatched,score} do not handle nil FONT_WEIGHT_INDEX Date: Thu, 30 Dec 2021 20:39:28 +0200 Message-ID: <8335mahr8f.fsf@gnu.org> References: <87zgoi8xve.fsf@melete.silentflame.com> <83r19uim2q.fsf@gnu.org> <871r1uyq1i.fsf@athena.silentflame.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25619"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 52888@debbugs.gnu.org To: Sean Whitton Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Dec 30 19:40:40 2021 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 1n30Lw-0006Rz-DP for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 30 Dec 2021 19:40:40 +0100 Original-Received: from localhost ([::1]:47688 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n30Lu-00050Y-Jk for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 30 Dec 2021 13:40:38 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:48636) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n30LK-0004zK-QM for bug-gnu-emacs@gnu.org; Thu, 30 Dec 2021 13:40:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:42904) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1n30LK-0001EQ-FS for bug-gnu-emacs@gnu.org; Thu, 30 Dec 2021 13:40:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1n30LK-0006TZ-4x for bug-gnu-emacs@gnu.org; Thu, 30 Dec 2021 13:40:02 -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, 30 Dec 2021 18:40:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 52888 X-GNU-PR-Package: emacs Original-Received: via spool by 52888-submit@debbugs.gnu.org id=B52888.164088957024838 (code B ref 52888); Thu, 30 Dec 2021 18:40:02 +0000 Original-Received: (at 52888) by debbugs.gnu.org; 30 Dec 2021 18:39:30 +0000 Original-Received: from localhost ([127.0.0.1]:54450 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n30Ko-0006SY-C3 for submit@debbugs.gnu.org; Thu, 30 Dec 2021 13:39:30 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:47708) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n30Km-0006SM-RH for 52888@debbugs.gnu.org; Thu, 30 Dec 2021 13:39:29 -0500 Original-Received: from [2001:470:142:3::e] (port=50878 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n30Kg-0001B2-WE; Thu, 30 Dec 2021 13:39:23 -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=wnSFYyLmskBYEkTjqLDis4DlYrqP9Ff81IvbWGo0z+4=; b=WHOzIs07fYB0 vLvNxuh0fWccjz/LXnHunT7cwRhcH5OWLdBsmeNtvU4HnLKfWmBbTYVNnVqTteNrd9L14t3CyPXN6 yxae0lrv0TCy+6ndyuzCLt1r6eg2vDmHf3zRv0IwN37Ee+AVcBEzrHUmsf/3OCDPerKYwPekypFmp Fn3rYldTAlf1rZzamufgT+MPiBWGpp9sFpbxDK4GhpFA57ZY4/i6LG4GkaJVu9BbMDda2t9m8RsEP wQFh/kIASCkVJzjsQlLJybamreDSVm/JLJ3MFmGtD5ELbbPyo6A+bn69zvlSxjd452b1QJr0Yl1kl FqiEWWfUDIObniNrv2hlVA==; Original-Received: from [87.69.77.57] (port=1323 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 1n30Kg-00071g-RI; Thu, 30 Dec 2021 13:39:23 -0500 In-Reply-To: <871r1uyq1i.fsf@athena.silentflame.com> (message from Sean Whitton on Thu, 30 Dec 2021 10:13:13 -0700) 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" Xref: news.gmane.io gmane.emacs.bugs:223439 Archived-At: > From: Sean Whitton > Cc: 52888@debbugs.gnu.org > Date: Thu, 30 Dec 2021 10:13:13 -0700 > > > Is the patch supposed to allow Emacs to handle these fonts, or is it > > just the protection against assertion violations? > > The latter -- the code implicitly assumes that the weight will always be > a fixnum, but that is not so. I want to fix that implicit assumption. > > > If the latter, isn't it better to teach the font driver to handle > > these fonts correctly? > > > > AFAIU, your patch basically will cause Emacs to reject such fonts and > > not use them, which is tantamount to telling users to configure Emacs > > to ignore them via, say, face-ignored-fonts. Is that right, or am I > > missing something? > > I don't think it is equivalent to face-ignored-fonts. The weight field > in the entity vector is examined only when the weight field in the font > spec is non-nil. So my code does not categorically reject these fonts: > it rejects them only when the user requested a specific weight, AFAICT. Does it really make sense to accept these fonts in some situations, but not in others? AFAIU, what you suggest would cause Emacs to accept these fonts when :weight is not mentioned (and so defaults to 'normal'), but to reject them if the 'normal' weight is specified explicitly, is that right? If so, it's confusing, and users will complain. Rejecting such fonts outright is at least consistent, and thus better than semi-support. > I don't know enough about these variable weight TTFs to judge whether it > is worth anyone's time adding better support for them in Emacs. In the > case of Inconsolata-VariableFont_wdth,wght.ttf, the font authors provide > separate .ttf files for each weight too, so there doesn't seem to be an > expectation that applications know how to read the combined file. I installed on the release branch a temporary fix, similar to what you suggested, to avoid undefined behavior with those fonts, but I don't think we should install something like that on master. On master, I think ftfont.c and its ilk should be fixed to handle these fonts correctly, or reject them if we cannot DTRT with them for some reason. I think the fact that we create invalid font entities from such fonts is a clear sign that the font backend mishandles them, and if so, that's where this problem should be corrected: we should create valid font entities to begin with, with ;weight and other similar attributes having numerical values, as expected. Thanks.