Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Crash when character has an glyph index but the glyph cannot be loaded #15

Open
RaZeR-RBI opened this issue Dec 6, 2021 · 6 comments · May be fixed by #16
Open

Crash when character has an glyph index but the glyph cannot be loaded #15

RaZeR-RBI opened this issue Dec 6, 2021 · 6 comments · May be fixed by #16
Assignees
@vladimirgamalyan
Labels
bug

Comments

@RaZeR-RBI
Copy link

Greetings! First of all, thanks for making this wonderful tool. I'm experiencing a crash when trying to render a font with some characters that exist in the font but for some reason cannot be loaded.

The following font file reproduces the issue for me - Hack-Regular.ttf. A sample char range that leads to crashing is 8300-8400. The message is 'Load glyph error'.

Here's what happens - isGlyphProvided reports true, then renderGlyph throws an exception because of FT_Load_Char failure.

For some reason shrinking the range towards the offending character sometimes fixes the issue, which makes me think that there could be a side effect from loading specific glyphs that affects the ones that are loaded afterwards. But it's just a speculation, I'm not very familiar with freetype internals so I may be way off. Since I'm using an autogenerated chars file shrinking the range is not an option for me (and there's no way of cleaning up the file without knowing which characters are offending).

TL;DR: Replacing FT_Get_Char_Index with FT_Load_Char (like in renderGlyph) fixes the issue, skipping the offending character (having incomplete font is better than no font, right?). I'll send a PR with this solution soon.
RaZeR-RBI added a commit to RaZeR-RBI/fontbm that referenced this issue Dec 6, 2021
@RaZeR-RBI
Fixed crash when glyph cannot be loaded (vladimirgamalyan#15)
c1ccb24
@RaZeR-RBI RaZeR-RBI linked a pull request Dec 6, 2021 that will close this issue
Open
@vladimirgamalyan
Copy link
Owner

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.

@vladimirgamalyan
Copy link
Owner

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.

@RaZeR-RBI
Copy link
Author

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?

@vladimirgamalyan
Copy link
Owner

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.

@vladimirgamalyan vladimirgamalyan self-assigned this Feb 17, 2022
@RaZeR-RBI
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@vladimirgamalyan vladimirgamalyan

Labels
bug
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Fixed crash when glyph cannot be loaded (#15) RaZeR-RBI/fontbm
3 participants
@RaZeR-RBI @vladimirgamalyan and others