Weird behaviour on missing font #263
Comments
|
What's happening here is that one of the implicit emoji fallback fonts is being used as the source of the cell metrics. Emoji fonts tend to have large dimensions because they're typically embedding bitmaps. Because the emoji fallback precedes a textual fallback the cells are oversized and yet still able to include text glyphs from a later fallback. |
|
I see. But is this the best fallback font? The cells seem VERY large. Could a more regular sized font be used? |
|
I'm still thinking about how best to resolve this; there are a couple of things to ponder:
|
|
Do you really have to check for / use an emoji font? If it's just a fallback font (in case you configured something wrong), maybe a textual font is good enough? Although you'd have to deal with / display emojis as text / error. Bundle a default font sounds like a good idea, especially if the system default font doesn't work, or just always default to a bundled font if the one in config is missing. The |
|
Re: |
These serve two purposes: * Provide a consistent default font for new installations, that happens to show off ligature and color emoji support out of the box. * Provide a reasonable fallback in case the configuration is broken Both fonts are distributed under the terms of the OFL 1.1. refs: #263
There was a flaw in processing the built-ins; because we searched the built-ins as part of the font dir step we'd satisfy matching the default fallback from the in-memory fonts and it would accidentally take precedence over the fonts provided by the system font locator. This commit makes an explicit additional (final) step to search the built in fonts. refs: #263
In this scenario:
```lua
local wezterm = require "wezterm"
return {
font_size = 12.0,
font_dirs = {"/home/wez/.fonts"},
font_locator = "ConfigDirsOnly",
font = wezterm.font_with_fallback({
-- this is an invalid font
"does not exist",
"Noto Color Emoji",
}),
}
```
we'd take the metrics from the emoji font and the cell size would
be crazy huge.
With this change we filter out "outliers" based on the approximate
pixel size for a font given its size and dpi. If a fallback position
is significantly larger or smaller than the theoretical size then
we skip it when considering the metrics.
The result of this is that with the above configuration we end up
with `{"Noto Color Emoji", "JetBrains Mono"}` as the font order;
most of the textual glyphs will render from `JetBrains Mono` but
the number glyphs prefer the `Noto Color Emoji` renditions which
are typically double width. While the terminal looks a bit
cartoonish as a result of that selection, the sizes are much more
reasonable compared to the screenshot in #263.
refs: #263
These serve two purposes: * Provide a consistent default font for new installations, that happens to show off ligature and color emoji support out of the box. * Provide a reasonable fallback in case the configuration is broken Both fonts are distributed under the terms of the OFL 1.1. refs: wez/wezterm#263
|
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further. |
Describe the bug
I had configured
.wezterm.luato load theFira Codefont with:font = wezterm.font("Fira Code")However i had uninstalled the font which caused some very weird visual bugs and long startup time.
Environment (please complete the following information):
To Reproduce
Open wezterm with the following configuration and with the font missing.
Configuration
Expected behavior
I would expect it to behave more gracefully and use the default font, with perhaps a message that the font is missing.
Screenshots
Additional context
The text was updated successfully, but these errors were encountered: