unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Sean Whitton <spwhitton@spwhitton.name>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 52888@debbugs.gnu.org
Subject: bug#52888: 29.0.50; font_{delete_unmatched,score} do not handle nil FONT_WEIGHT_INDEX
Date: Wed, 05 Jan 2022 22:41:55 -0700	[thread overview]
Message-ID: <87czl55skc.fsf@melete.silentflame.com> (raw)
In-Reply-To: <83tuei9x3v.fsf@gnu.org>

[-- Attachment #1: Type: text/plain, Size: 1896 bytes --]

Hello,

On Wed 05 Jan 2022 at 02:37PM +02, Eli Zaretskii wrote:

> 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.

Ah, right.  Is this version bound written down anywhere other than the
conditionals in configure.ac?  Sorry I didn't think to look there.

> 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.

My patch requires FC_VARIABLE which was not added until 2.12.91, so in
the attached revision I've set up preprocessor conditionals based on
FC_VARIABLE.  Checking that FC_VARIABLE is true is how we know it's one
of the virtual entries.

It looks like fontconfig commit 83b41611 introduced the meta patterns
under discussion.  The first tagged release including that commit is
2.12.91.  So AFAICT nothing of the old fix need remain.

> 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:

Yes, I was surprised too, but as has been mentioned, the FcPatternGet*
functions are documented as supplying pointers to storage which must not
be freed.

-- 
Sean Whitton

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: v2-0001-Skip-virtual-FcPattern-entries-for-variable-weigh.patch --]
[-- Type: text/x-patch, Size: 1789 bytes --]

From d88f23882b66243b42d79e0fe897f99f8125c7c4 Mon Sep 17 00:00:00 2001
From: Sean Whitton <spwhitton@spwhitton.name>
Date: Tue, 4 Jan 2022 19:07:29 -0700
Subject: [PATCH v2] Skip virtual FcPattern entries for variable weight fonts

* src/ftfont.c (ftfont_list): Pass FC_VARIABLE to FcObjectSetBuild.
* src/ftfont.c (ftfont_pattern_entity): Skip meta/virtual FcPattern
entries for variable weight fonts (Bug#52888).
---
 src/ftfont.c | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/src/ftfont.c b/src/ftfont.c
index 2bdcce306b..6bfbc50ffa 100644
--- a/src/ftfont.c
+++ b/src/ftfont.c
@@ -189,6 +189,19 @@ ftfont_pattern_entity (FcPattern *p, Lisp_Object extra)
     return Qnil;
   if (FcPatternGetInteger (p, FC_INDEX, 0, &idx) != FcResultMatch)
     return Qnil;
+#ifdef FC_VARIABLE
+  FcRange *range;
+  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;
+#endif	/* FC_VARIABLE */
 
   file = (char *) str;
   key = Fcons (build_unibyte_string (file), make_fixnum (idx));
@@ -863,6 +876,9 @@ ftfont_list (struct frame *f, Lisp_Object spec)
 #if defined HAVE_XFT && defined FC_COLOR
                              FC_COLOR,
 #endif
+#ifdef FC_VARIABLE
+			     FC_VARIABLE,
+#endif	/* FC_VARIABLE */
 			     NULL);
   if (! objset)
     goto err;
-- 
2.30.2


  parent reply	other threads:[~2022-01-06  5:41 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-30  5:28 bug#52888: 29.0.50; font_{delete_unmatched,score} do not handle nil FONT_WEIGHT_INDEX Sean Whitton
2021-12-30  7:33 ` Eli Zaretskii
2021-12-30 17:13   ` Sean Whitton
2021-12-30 18:39     ` Eli Zaretskii
2022-01-01  0:30       ` Sean Whitton
2022-01-01  2:35         ` Sean Whitton
2022-01-01  7:15           ` Eli Zaretskii
2022-01-01 22:31             ` Sean Whitton
2022-01-03  2:04               ` Sean Whitton
2022-01-05  2:10             ` Sean Whitton
2022-01-05 12:37               ` Eli Zaretskii
2022-01-05 13:55                 ` Robert Pluim
2022-01-05 14:08                   ` Eli Zaretskii
2022-01-06  5:41                 ` Sean Whitton [this message]
2022-01-06 12:29                   ` Eli Zaretskii
2022-01-06 18:10                     ` Sean Whitton
2022-01-12 14:56                       ` Eli Zaretskii
2022-01-12 21:41                         ` Sean Whitton
2022-01-13  6:52                           ` Eli Zaretskii
2022-01-01  6:56         ` Eli Zaretskii
     [not found]           ` <87pmpbm8j2.fsf@melete.silentflame.com>
     [not found]             ` <83v8z2eizk.fsf@gnu.org>
     [not found]               ` <87pmp9wyo3.fsf@melete.silentflame.com>
     [not found]                 ` <83r19pc8ax.fsf@gnu.org>
     [not found]                   ` <87v8yzb1v7.fsf@melete.silentflame.com>
     [not found]                     ` <83v8yy9ybv.fsf@gnu.org>
2022-01-06 18:20                       ` bug#53058: etc/DEBUG could say more about --enable-check-lisp-object-type Sean Whitton
2022-01-06 20:11                         ` Eli Zaretskii
2022-01-06 23:46                           ` Sean Whitton
2022-01-07  6:58                             ` Eli Zaretskii
2022-01-07 20:41                               ` Sean Whitton
2022-01-08  6:55                                 ` Eli Zaretskii
2022-02-03  0:19                                   ` Sean Whitton
2022-02-03  7:28                                     ` Eli Zaretskii
2022-01-13 11:54 ` bug#52888: André Silva
2022-01-13 16:40   ` bug#52888: Eli Zaretskii
     [not found]     ` <CANfyKeBjec0z2c33Fph1=ESr-4ACH0BNKXq_wW-Vtr6sEfJ_VA@mail.gmail.com>
2022-01-13 18:13       ` bug#52888: Eli Zaretskii
     [not found]         ` <CANfyKeD2-sP4tO0dH0rbjbyD+rR+ahiDgBn+Pnx89EG1iKqiYg@mail.gmail.com>
2022-01-13 19:49           ` bug#52888: Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87czl55skc.fsf@melete.silentflame.com \
    --to=spwhitton@spwhitton.name \
    --cc=52888@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).