Crash when character has an glyph index but the glyph cannot be loaded about fontbm HOT 5 OPEN

Sorry for late. I come back to this issue from time to time, but I can't figure out how to fix it better yet. I don't want to just hide the error (because users expect correct fonts in the output). Also, I'm not sure if we should use static linking of the fresh freetype lib.
I will try to think more and maybe I will come to some solution.

from fontbm.

Hi! Thank you! Nice catch!
I've reproduced the issue with the same result. It seems like FreeType goes to a weird state after rendering some glyphs when using own autohinter (with font's hinter the problem disappears). For example, characters 8330 and 8377 rendered well alone, but not one by one. As workaround I try to reload font on error, it works so far, but I think it needs further investigation.

from fontbm.

It looks like there a some bug in FreeType version < 2.11. I've updated github build actions and AppVeyor scripts to use a fresh FreeType version. The last release works good so far.

from fontbm.

It looks like there a some bug in FreeType version < 2.11. I've updated github build actions and AppVeyor scripts to use a fresh FreeType version. The last release works good so far.

Just tested it on my dev machine running Debian Bullseye and sadly it still crashes because the executable is dynamically linked to freetype (confirmed with readelf -d), and my system's (and package repo's) freetype version is 2.10.4.

I guess I'll use my patched version for now, but the question whether should we make a workaround (by using my patch or something other) or not is still open. What do you think?

from fontbm.

Sorry for late. I come back to this issue from time to time, but I can't figure out how to fix it better yet. I don't want to just hide the error (because users expect correct fonts in the output). Also, I'm not sure if we should use static linking of the fresh freetype lib. I will try to think more and maybe I will come to some solution.

No worries, I've just examined it for a hobby project so there's no any time pressure at all.
I'd personally not go the static link way because I'm afraid that it can possibly bring more issues than it can solve, however, if you don't want to hide the error (which is understandable) I think it's then possible to add a command line option to skip offending characters if the user accepts that behavior, as a workaround.

from fontbm.