Subject: bug#33885: 27.0.50; PUA character makes emacs crash

From: Werner LEMBERG <[email-masked]>
Date: Fri, 28 Dec 2018 15:58:50 +0100 (CET)

>> We rather have to check how the `Cardo' fonts get loaded into
>> Emacs; it looks as if the global font descent value is incorrect.
>> Please tell me (a) how to identify the font used for U+E6A3, and
>> (b) where to set a breakpoint to see the font loading in action.
> 
> (a) font->props[2] names the font, so:
> 
>   (gdb) pp font->props[2]
> 
> should display its name in human-readable form.

Thanks.  This indeed gives `Cardo'.

> (b) Given your list of features, which includes XFT, I think you
> want to set a breakpoint in xftfont_open, where there's a call to
> XftFontOpenPattern.

OK.  `XftFontOpenPattern' returns the following data for `Cardo':

(gdb) p *xftfont
$12 = {
  ascent = 16, 
  descent = -5, 
  height = 6, 
  max_advance_width = 91, 
  charset = 0x7fffe23d52d8, 
  pattern = 0x1f01050
}

This is problematic, since it only reflects the Apple values for
ascent and descent (i.e., the data in the font's `hhea' table).  To
solve the issue, there are two possible solutions IMHO.

(1) Simply accept whatever `XftFontOpenPattern' returns, including
    negative values for `descent' – actually, such font might exist:
    for example, consider a special font that only contains dashes of
    different length.

(2) Improve the heuristics to get sensible global ascent and descent
    values of a font.  In particular, use the FreeType library to
    access a TrueType's or OpenType's `OS/2' table and compare its
    vertical metrics values with the `hhea' data to eliminate bugs in
    the font – sign problems with `descent' do happen especially in
    older fonts that were either designed for Apple or for Windows,
    and the fields for the `other' OS were filled out arbitrarily,
    more or less.

      Werner