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: Wed, 05 Jan 2022 14:37:56 +0200 Message-ID: <83tuei9x3v.fsf@gnu.org> References: <87bl0raq55.fsf@melete.silentflame.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="35775"; 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 Wed Jan 05 14:03:52 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 1n55xH-00096t-Gw for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 05 Jan 2022 14:03:51 +0100 Original-Received: from localhost ([::1]:46490 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n55xE-0003FZ-RK for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 05 Jan 2022 08:03:49 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:34050) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n55YI-0005iT-Tu for bug-gnu-emacs@gnu.org; Wed, 05 Jan 2022 07:38:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:56406) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1n55YI-00015Z-KV for bug-gnu-emacs@gnu.org; Wed, 05 Jan 2022 07:38:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1n55YI-00027A-Ge for bug-gnu-emacs@gnu.org; Wed, 05 Jan 2022 07:38: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: Wed, 05 Jan 2022 12:38: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.16413862758109 (code B ref 52888); Wed, 05 Jan 2022 12:38:02 +0000 Original-Received: (at 52888) by debbugs.gnu.org; 5 Jan 2022 12:37:55 +0000 Original-Received: from localhost ([127.0.0.1]:39719 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n55YB-00026j-Bp for submit@debbugs.gnu.org; Wed, 05 Jan 2022 07:37:55 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:33260) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n55Y9-00026W-LC for 52888@debbugs.gnu.org; Wed, 05 Jan 2022 07:37:54 -0500 Original-Received: from [2001:470:142:3::e] (port=40536 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 1n55Y3-00014b-TD; Wed, 05 Jan 2022 07:37:48 -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=xG1JHXyRtQQ6hcgCkYmFW+Vqfp58GDpDKpaIZfMTSNw=; b=SX0XNk2AuZfe Sl436JolAvZ1fCs210jON9q7AQzI2LjdrkvtR8HInhKcCcRB4dOqysz0DEIMd1NY9Os0FatFteyq7 AsOVxNbLupUoOa2YuV98zGkcb9EsHi3rB/vmYVr913giz7S0lnRaltSxeKWyVI1VPEi7H4Ib5jVMr TsmfkQ9+BXnAaFj+N/Iu+8KfG8bxLmR/3sgi/lut8GUAU9KxjmwzQxvdsHL2xvTurV1SufNd7FFwU 7nKpXBIjRd7g5aK8Y+Qtaxk/DlQIp9HKJKvn5mD6s89QWWV6fEz3l8VLk9Mhzt1Uz/cSj5fZ3+QBh s4iUsSyR1OUygv49O8+uCw==; Original-Received: from [87.69.77.57] (port=3081 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 1n55Y3-0007Om-QC; Wed, 05 Jan 2022 07:37:48 -0500 In-Reply-To: <87bl0raq55.fsf@melete.silentflame.com> (message from Sean Whitton on Tue, 04 Jan 2022 19:10:46 -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:223687 Archived-At: > From: Sean Whitton > Date: Tue, 04 Jan 2022 19:10:46 -0700 > > I received a helpful reply from Akira TAGOH on the fontconfig list. The > problematic entries are not in fact additional font weights available to > Emacs, but meta or virtual entries from which applications can extract > information about the range of weights provided by the variable weight > .ttf file. > > As we do not need to know the range of weights explicitly, the virtual > entries are no use to us. We can just skip over them and process the > non-virtual FcPattern entries we get for each weight. I'm attaching a > patch which detects these virtual entries and skips over them. Thanks, very good news! > Maybe we could revert and replace the temporary fix with my patch? According to what I see in the documentation, FcPatternGetRange exists only since version 2.11.91 of Fontconfig, whereas we support 2.2.0 and up. So we cannot unconditionally use that API, and some part of the temporary solution will have to be left in the source. I'd need to see the final patch with that in mind, before I can decide whether it is simple/safe enough for the release branch. > --- a/src/ftfont.c > +++ b/src/ftfont.c > @@ -184,11 +184,22 @@ ftfont_pattern_entity (FcPattern *p, Lisp_Object extra) > int numeric; > double dbl; > FcBool b; > + FcRange *range; > > if (FcPatternGetString (p, FC_FILE, 0, &str) != FcResultMatch) > return Qnil; > if (FcPatternGetInteger (p, FC_INDEX, 0, &idx) != FcResultMatch) > return Qnil; > + if (FcPatternGetRange (p, FC_WEIGHT, 0, &range) == FcResultMatch > + && FcPatternGetBool (p, FC_VARIABLE, 0, &b) == FcResultMatch > + && b == FcTrue) > + /* This is a virtual/meta FcPattern for a variable weight font, > + from which it is possible to extract an FcRange value > + specifying the minimum and maximum weights available in this > + file. We don't need to know that information explicitly, so > + skip it. We will be called with an FcPattern for each actually > + available, non-virtual weight. */ > + return Qnil; I'm far from being an expert on Fontconfig programming, but the above use of 'range' looks strange: it's a pointer that starts pointing to some random (potentially invalid) address, and you pass its address to FcPatternGetRange, which presumably assigns to it a valid point. But doesn't that valid pointer need to be released somehow after we use it? Or does it point to static area(s)? I cannot find anything in the Fontconfig documentation about the memory-management protocols for FcValue objects, but maybe we should call FcValueDestroy on it after we are done with it? Or maybe this is not needed, as this passage from the docs says near the end: void FcValueDestroy (FcValue v) Frees any memory referenced by `v'. Values of type FcTypeString, FcTypeMatrix and FcTypeCharSet reference memory, the other types do not. Thanks.