GNU bug report logs - #30874
Displaying char \x274C with Dejavu Sans Mono gives "X protocol error: BadLength (poly request too large or internal Xlib length error) on protocol request 138"

Previous Next

Full log

View this message in rfc822 format

From: Robert Pluim <rpluim <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 30874 <at> debbugs.gnu.org, jsynacek <at> redhat.com
Subject: bug#30874: 27.0.50; Emacs crashes
Date: Tue, 27 Mar 2018 10:57:03 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

> So how do we end up loading that problematic font, and why does that
> happen with the recipe for this bug, but not if set-fonset-font on the
> command line is omitted?

Hereʼs what the file loading looks like from Xft's perspective:

XFT_DEBUG=16 LD_LIBRARY_PATH=/home/rpluim/repos/src/libXft-2.3.2/src/.libs/ ./emacs -Q

XFT_DEBUG=16
FontFile /home/rpluim/.local/share/fonts/Inconsolata-Regular.ttf/0 matches new
Loading file /home/rpluim/.local/share/fonts/Inconsolata-Regular.ttf/0
FontFile /home/rpluim/.local/share/fonts/Inconsolata-Regular.ttf/0 matches existing (2)
FontFile /usr/share/fonts/inconsolata/Inconsolata-Bold.ttf/0 matches new
Loading file /usr/share/fonts/inconsolata/Inconsolata-Bold.ttf/0

# Inconsolata is my system default monospace font. Now I insert #x274c :

FontFile /usr/share/fonts/inconsolata/Inconsolata-Regular.ttf/0 matches new
Loading file /usr/share/fonts/inconsolata/Inconsolata-Regular.ttf/0
FontFile /usr/share/fonts/vlgothic/VL-Gothic-Regular.ttf/0 matches new
Loading file /usr/share/fonts/vlgothic/VL-Gothic-Regular.ttf/0

# I think this means Inconsolata doesnʼt have a glyph for that
# codepoint, although I thought the default fontset specified Symbola
# for that codepoint (and Symbola is installed), so I donʼt understand
# why VL-Gothic is chosen.
# Now I change the fontset, and this time it finds the
# emojione-android font :
  
FontFile /usr/share/fonts/dejavu/DejaVuSansMono.ttf/0 matches new
Loading file /usr/share/fonts/dejavu/DejaVuSansMono.ttf/0
FontFile /home/rpluim/.local/share/fonts/Inconsolata-Regular.ttf/0 matches existing (2)
FontFile /usr/share/fonts/eosrei-emojione/emojione-android.ttf/0 matches new
Loading file /usr/share/fonts/eosrei-emojione/emojione-android.ttf/0

> It looks like this is a problem with all color emoji fonts, so this is
> indeed a duplicate of bug#30045.  See this bug:
>
>   https://bugzilla.redhat.com/show_bug.cgi?id=1498269
>
> The question now becomes: how do we avoid loading such fonts, at least
> when the xftfont back-end is in use?  Is there any alternative except
> telling users to "move such fonts out of the way"?

Accoding to that bug, the solution is for the application to 'move
away from legacy Xft to fontconfig', whatever that means. I can say
that building '--without-xft' is definitely sub-optimal (the buffer
text isnʼt scaled, and Emacs doesnʼt find a font to display #x274c).

Robert

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.