wez / wezterm

A GPU-accelerated cross-platform terminal emulator and multiplexer written by @wez and implemented in Rust
https://wezfurlong.org/wezterm/
Other
16.67k stars 745 forks source link

wezterm reports being unable to load font specified in configuration while the font being seemingly available. #1137

Closed jubalfh closed 3 years ago

jubalfh commented 3 years ago

What Operating System(s) are you seeing this problem on?

Windows

WezTerm version

20210909-091634-1f97a832

Did you try the latest nightly build to see if the issue is better (or worse!) than your current version?

Yes, and I updated the version box above to show the version of the nightly that I tried

Describe the bug

When running wezterm with the configuration as quoted below, wezterm complains a bit (using a dedicated window) about substituting fallback font.

Which would be perfectly fine (I haven't suppressed this behaviour), would it also not report that the font with the exact specific parameters is available when running the ls-fonts --list-system command…

Note: this does not happen when the first font on the list is Iosevka SS07. Also, this only happens on Windows, on Linux this configuration does not report any errors.

To Reproduce

probably the easiest way to reproduce is to run the following either in cmd or in pwsh:

$ 'C:\Program Files\WezTerm\wezterm.exe' ls-fonts --list-system | gawk "/Iosevka Term SS07/ &&/Regular/ && /Normal/ && /italic=false/ { print }"

which produces the following error message:

Unable to load a font specified by your font=wezterm.font('Iosevka Term SS07', {weight="Regular", stretch='Normal', italic=false}) configuration. Fallback(s) are being used instead, and the terminal may not render as intended. See https://wezfurlong.org/wezterm/config/fonts.html for more information

…and the following awk output:

wezterm.font("Iosevka Term SS07", {weight="Regular", stretch="Normal", italic=false}) -- C:\WINDOWS\FONTS\IOSEVKA-SS07.TTC index=55 variation=0, DirectWrite

Configuration

the configuration is rather basic:

local term = require 'wezterm';
local keys = {};

return {
    window_padding = {2, 2, 2, 2},
    window_decorations = "RESIZE",
    enable_tab_bar = false,
    use_ime = true,
    color_scheme = "Gruvbox Dark",
    font = term.font_with_fallback({
        "Iosevka Term SS07",
        "Iosevka SS07",
        "Iosevka Term",
    }),
    font_size = 12,
    freetype_load_target = "Light",
    freetype_render_target = "HorizontalLcd",
    freetype_interpreter_version = 40,
}

Expected Behavior

No error messages and no need to suppress them.

Logs

miroslaw at MORDOR in ~
$ wezterm
 2021-09-12T11:56:10.362Z INFO  wezterm_mux_server_impl::local > setting up C:\Users\miroslaw\.local/share/wezterm\gui-sock-7684
 2021-09-12T11:56:10.825Z ERROR mux::connui                    > Configuration Error: Unable to load a font specified by your font=wezterm.font('Iosevka Term SS07', {weight="Regular", stretch='Normal', italic=false}) configuration. Fallback(s) are being used instead, and the terminal may not render as intended. See https://wezfurlong.org/wezterm/config/fonts.html for more information
 2021-09-12T11:56:10.839Z WARN  wezterm_term::terminalstate    > unhandled DecPrivateMode SetDecPrivateMode(Unspecified(9001))
 2021-09-12T11:56:10.976Z INFO  wezterm_gui::termwindow        > OpenGL initialized! ANGLE (Intel(R) HD Graphics 620 Direct3D11 vs_5_0 ps_5_0) OpenGL ES 3.0.0 (ANGLE 2.1.1 git hash: 07ea804e6201) is_context_loss_possible=true wezterm version: 20210814-124438-54e29167

Anything else?

No response

wez commented 3 years ago

Please set WEZTERM_LOG=wezterm_font::locator::gdi=trace,info in the environment and run wezterm ls-fonts, and share the output here; that might give some more clues about what is happening.

jubalfh commented 3 years ago

here's the output: wezterm_ls_fonts_output.txt

got this with the nightly build and the following:

miroslaw at MORDOR in ~
$ wezterm ls-fonts 2>&1 > wezterm_ls_fonts_output.txt

miroslaw at MORDOR in ~
$ which wezterm
C:\Program Files\WezTerm\wezterm.EXE
wez commented 3 years ago

I believe this to be fixed in the commit that I just pushed; that should show up in the nightly downloads within 30 minutes of the time of writing this message; please let me know if it works for you!

jubalfh commented 3 years ago

yup, i'm not seeing this issue anymore, thank you muchly :-)

github-actions[bot] commented 1 year ago

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.