GNU bug report logs - #33885
27.0.50; PUA character makes emacs crash

Previous Next

Package: emacs;

Reported by: Werner LEMBERG <wl <at> gnu.org>

Date: Thu, 27 Dec 2018 08:56:01 UTC

Severity: normal

Tags: moreinfo

Found in version 27.0.50

Fixed in version 29.1

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Werner LEMBERG <wl <at> gnu.org>
Cc: 33885 <at> debbugs.gnu.org
Subject: bug#33885: 27.0.50; PUA character makes emacs crash
Date: Fri, 28 Dec 2018 11:16:17 +0200
> Date: Fri, 28 Dec 2018 09:33:33 +0100 (CET)
> Cc: bug-gnu-emacs <at> gnu.org, 33885 <at> debbugs.gnu.org
> From: Werner LEMBERG <wl <at> gnu.org>
> 
> ... a font that *does* have this character (following the MUFI
> standard to display characters for medieval research).
> 
>   https://folk.uib.no/hnooh/mufi/
> 
> The font in question is `Cardo Regular', Version 1.045, which you
> can freely download as
> 
>   http://scholarsfonts.net/cardo104.zip
> 
> (Note that the Google variant of this font doesn't contain the MUFI
> characters.)
> 
> Character U+E6A3 gets mapped to glyph 3817, `uni00720325', which is
> glyph `r' with a ring below; the `ttx' font disassembler shows the
> following entry from the font's `glyf' table:
> 
>   <TTGlyph name="uni00720325" xMin="52" yMin="-510" xMax="747" yMax="927">
>     <component glyphName="r" x="0" y="0" flags="0x204"/>
>     <component glyphName="ring" x="-39" y="-1589" flags="0x4"/>
>   </TTGlyph>

Does this explain why the descent comes out negative?  (I'm not an
expert on font metrics.)

> > So please step through x_produce_glyphs when Emacs needs to produce
> > a glyph for this character, and tell how you end up with both ascent
> > and descent values zero.  It isn't supposed to happen with valid
> > fonts.
> 
> Uh, oh, I'm completely lost in this function; nowhere I can get
> information on the font's name.  Additionally, there is no repeatable
> way to set a breakpoint right before the crash; the number of
> iterations are different each time.

The way I would suggest to put a useful breakpoint there is this:

  break x_produce_glyphs if it->char_to_display == 0xe6a3

See also a few more questions I asked in the follow-up message.

(I will try to install that font, but that might take a few days.  In
the meantime, if you can report the additional information, I might be
able to come up with a patch even without installing the font and
reproducing the problem here.)

Thanks.




This bug report was last modified 3 years and 73 days ago.

Previous Next


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