bug#25945: Emacs aborts while calling FT_Load_Glyph

[Eli Zaretskii <eliz@gnu.org>]

> Date: Fri, 03 Mar 2017 09:32:17 +0100 (CET)
> Cc: handa@gnu.org, 25945@debbugs.gnu.org
> From: Werner LEMBERG <wl@gnu.org>
> 
> > This should probably be accompanied by a suitable FONT_ADD_LOG call,
> > to mention that this fallback was taken.
> 
> Yes, perhaps.  However, if all glyphs are broken you will get a huuge
> logfile...

It's not a file, it's a buffer.  And the log is actually only added if
a special variable is non-nil, which only happens when one wants to
debug font issues.

> >> My knowledge of Emacs internals is too small to provide an
> >> implementation for (b).
> > 
> > I think it's too late for (b) when we discover this problem in
> > ftfont_get_metrics.  To do (b) we should have discovered this in
> > ftfont_has_char, or thereabouts.
> 
> Interesting.  How comes that Emacs aborts right there?

Sorry, I don't understand the question.  If you are asking why there's
a call to emacs_abort if FT_Load_Glyph fails, then I guess it''s
because this is unexpected and we have no code capable of coping with
such a calamity.

> A note regarding the Padauk font: The problem is partly due to
> FreeType 2.7.1, which has a stricter looping limit for TrueType
> bytecode to detect endless loops – for this font, however, the limit
> is a bit too strict; I will fix this in the next FreeType release.
> Regardless of that, the bytecode in Padauk *is* buggy, and I've
> already contacted the maintainers, asking for a new release using a
> new, fixed ttfautohint version.
> 
>   https://github.com/silnrsi/font-padauk/issues/12

Thanks for the info.