Graceful handling of font files that fail to load (invalid font tables, bad format, etc.)

[qwerasd205]

We need to handle bad fonts (corrupted, or unsupported due to missing tables) better. Currently they cause rendering issues when they appear as fallbacks and they cause straight up crashes when set as the primary font. We need to handle this gracefully, and the font discovery mechanism(s) need to be updated to exclude bitmap fonts.

[anund]

ghostty --font-family=Fixed is an example. Its a ~default font shipped as part of X11 I noticed used to produced scrambled text and now crashes.

[mitchellh]

ghostty --font-family=Fixed is an example. It's a ~default font shipped as part of X11 I noticed used to produced scrambled text and now crashes.

The crash seems like a separate bug that should be fixed.

[mitchellh]

I renamed the issue slightly in case anyone browsing our issue list is confused by this. I don't know if the rename helped but I didn't want people to think we didn't handle non-existent fonts. This issue is about fonts that exist that are invalid for whatever reason and we haven't programmed a way to handle it.

[Andriamanitra]

This issue caused font rendering to break for me when printing Thai numerals ¹ because Ghostty would fall back to a bitmap font ² which are not supported, even though I would have also had TrueType font with Thai glyphs (Noto Sans Thai) to fall back to.

To reproduce:

printf "THAI DIGIT SEVEN: -> \u0e57 <-\n"

or

$ ghostty +show-face --cp=0xE57
Unable to get face: error.CopyTableError

After the printf ghostty would log something like this (the warning about CopyTableError was repeatedly printed every ~0.5 seconds or so after the fallback was found):

info(font_codepoint_resolver): found codepoint 0xE57 in fallback face=Fixed Regular
warning(renderer_thread): error rendering err=error.CopyTableError
warning(renderer_thread): error rendering err=error.CopyTableError
warning(renderer_thread): error rendering err=error.CopyTableError
warning(renderer_thread): error rendering err=error.CopyTableError
warning(renderer_thread): error rendering err=error.CopyTableError
warning(renderer_thread): error rendering err=error.CopyTableError
warning(renderer_thread): error rendering err=error.CopyTableError
warning(renderer_thread): error rendering err=error.CopyTableError
warning(renderer_thread): error rendering err=error.CopyTableError
warning(renderer_thread): error rendering err=error.CopyTableError

---

To work around the issue you can explicitly choose a font that has the glyph:

$ ghostty --font-family="Noto Sans Thai"  +show-face --cp=0xE57
U+E57 « ๗ » found in face “Noto Sans Thai”.

this can also be specified as a secondary font in ~/.config/ghostty/config, you can pick multiple fonts like this:

font-family = Source Code Pro Semibold  # My preferred font
font-family = Noto Sans Thai

Footnotes

1. screencast ↩

2. /usr/share/fonts/misc/h14.pcf.gz (Fixed Regular) in my case but I think any Unicode bitmap font would cause the same problem. Another Discord user was able to reproduce the bug after running sudo dnf install efont-unicode-bdf on Fedora. ↩

[dyrkuwu]

I can confirm its an issue with unicode bitmap font rendering as it crashes with Cozette.

[mitchellh]

This should be mitigated significantly with #3550 on macOS. This prevents macOS from using CoreText in the fallback chain (or any chain really). This will be part of 1.0.1.

[mitchellh]

Removing this issue from 1.0.1 since the mitigation is in place. Keeping the issue open to address more robustly in the future.