From: Robert Pluim <rpluim@gmail.com>
To: Allen Li <darkfeline@felesatra.moe>
Cc: 37786@debbugs.gnu.org
Subject: bug#37786: 26.3; Emacs crashes when calling function to decode string
Date: Tue, 05 Nov 2019 18:40:28 +0100 [thread overview]
Message-ID: <m2pni6te5v.fsf@gmail.com> (raw)
In-Reply-To: <m25zkar3us.fsf@gmail.com> (Robert Pluim's message of "Sun, 27 Oct 2019 09:26:35 +0100")
[-- Attachment #1: Type: text/plain, Size: 1242 bytes --]
>>>>> On Sun, 27 Oct 2019 09:26:35 +0100, Robert Pluim <rpluim@gmail.com> said:
>>>>> On Sat, 26 Oct 2019 02:44:52 -0700, Allen Li <darkfeline@felesatra.moe> said:
>>> Hmm. Could you try the following against emacs-26 and see if it fixes
>>> your crash? (the character will almost certainly end up displayed
>>> wrong). This looks more like a fontconfig bug than anything else: the
>>> pattern we've supplied to FcFontList explicitly says "donʼt give me
>>> color fonts".
Allen> Yep, this fixes the crash and I get the box with unicode codepoint
Allen> inside. I don't know anything about fontconfig, so I can't comment on
Allen> whether this is a fontconfig bug.
Robert> Thanks for testing. Iʼll have to write a standalone test case against
Robert> fontconfig before I can say whether itʼs a fontconfig bug or not, in
Robert> the meantime Iʼll clean up the patch.
I think itʼs a fontconfig bug, but Iʼve received no response from the
fontconfig guys. Perhaps I need to use their new-fangled issue tracker
thing rather than good old email. In any case, both Arch and Fedora 31
have fontconfig packages with this issue, so we need to paper^Wfix the
issue our end.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Ignore-color-fonts-returned-from-FcFontList.patch --]
[-- Type: text/x-patch, Size: 1696 bytes --]
From aabd13bba282563410ef95764cad39f02ecb5d84 Mon Sep 17 00:00:00 2001
From: Robert Pluim <rpluim@gmail.com>
Date: Mon, 4 Nov 2019 17:44:57 +0100
Subject: [PATCH] Ignore color fonts returned from FcFontList
To: emacs-devel@gnu.org
* src/ftfont.c (ftfont_list): [HAVE_XFT && FC_COLOR]: Ask FcFontList
to return FC_COLOR attribute. Check returned attribute for
non-FcFalse, since some color fonts have a color attribute that's
neither FcFalse nor FcTrue (Bug#37786).
---
src/ftfont.c | 17 ++++++++++++++++-
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/src/ftfont.c b/src/ftfont.c
index 77a4cf5de5..b066f55a18 100644
--- a/src/ftfont.c
+++ b/src/ftfont.c
@@ -864,6 +864,9 @@ ftfont_list (struct frame *f, Lisp_Object spec)
#endif /* FC_CAPABILITY */
#ifdef FC_FONTFORMAT
FC_FONTFORMAT,
+#endif
+#if defined HAVE_XFT && defined FC_COLOR
+ FC_COLOR,
#endif
NULL);
if (! objset)
@@ -904,7 +907,19 @@ ftfont_list (struct frame *f, Lisp_Object spec)
for (i = 0; i < fontset->nfont; i++)
{
Lisp_Object entity;
-
+#if defined HAVE_XFT && defined FC_COLOR
+ {
+ /* Some fonts, notably NotoColorEmoji, have an FC_COLOR value
+ that's neither FcTrue nor FcFalse, which means FcFontList
+ returns them even when it shouldn't really do so, so we
+ need to manually skip them here (Bug#37786). */
+ FcBool b;
+ if (Vxft_ignore_color_fonts
+ && FcPatternGetBool (fontset->fonts[i], FC_COLOR, 0, &b)
+ == FcResultMatch && b != FcFalse)
+ continue;
+ }
+#endif
if (spacing >= 0)
{
int this;
--
2.19.1.816.gcd69ec8cde
next prev parent reply other threads:[~2019-11-05 17:40 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-17 4:11 bug#37786: 26.3; Emacs crashes when calling function to decode string Allen Li
2019-10-17 4:22 ` Lars Ingebrigtsen
2019-10-17 9:53 ` Robert Pluim
2019-10-18 4:28 ` Allen Li
2019-10-18 9:49 ` Robert Pluim
2019-10-19 1:18 ` Allen Li
2019-10-21 10:02 ` Robert Pluim
2019-10-22 3:44 ` Allen Li
2019-10-22 8:18 ` Robert Pluim
2019-10-23 3:25 ` Allen Li
2019-10-25 16:32 ` Robert Pluim
2019-10-26 9:44 ` Allen Li
2019-10-27 8:26 ` Robert Pluim
2019-11-05 17:40 ` Robert Pluim [this message]
2019-11-13 14:03 ` Robert Pluim
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=m2pni6te5v.fsf@gmail.com \
--to=rpluim@gmail.com \
--cc=37786@debbugs.gnu.org \
--cc=darkfeline@felesatra.moe \
/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).