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

Can't configure Iosevka Term Light Italic in new nightly #873

Closed guswynn closed 3 years ago

guswynn commented 3 years ago

Describe the bug

My config: https://github.com/guswynn/dotfiles/commit/7cb6c554315548659a5a7c9dbe880bfb399144c6

was forced to switch to Iosevka Term Light Oblique recently, as I could not get Iosevka Term Light Italic to work.

This is very curious as Iosevka Term Light and Iosevka Term Light Oblique as fonts work, but Iosevka Term Light Italic as well as Iosevka Term Light+{italic=true} both dont work.

Looking at font book, I definitely have Iosevka Term Light Oblique AND Iosevka Term Light Italic installed, so its unclear to me why I can't select the specific light italic font, but can select the oblique one

When I did this on stable a while ago, you can see that I ended up using Iosevka Term Light+{italic=true} to select this font, and I believe it worked (I didn't get errors), but now, as the above mentions, I can't seem to select that specific font in any way. My guess is that its this code: https://github.com/wez/wezterm/blob/c37ee012226da9ebbbe37daa56285af6860da030/config/src/font.rs#L340 trimming await the Italic and the Light. This appears to correctly work with the default font I have (Iosevka Term Light), but for some reason, applying the italic=true to it makes it fail, as shown below.

Environment (please complete the following information):

Screenshots

font_with_fallback("Iosevka Term Light Italic", {italic=true}),: image

font_with_fallback("Iosevka Term Light", {italic=true}), image

font_with_fallback("Iosevka Term", {italic=true, weight="Light"}), looks different (very light in color): image and isn't actually the Iosevka Term Light Italic font (as far as I can tell)

wez commented 3 years ago

font_with_fallback("Iosevka Term", {italic=true, weight="Light"}), is probably what you want; at least, the intent is that that is the correct way to specify the family, weight and italic style for a font.

You can run:

WEZTERM_LOG=wezterm_font=debug wezterm ls-fonts

to print diagnostics about the fonts; the debug logging there will also list information about available fonts found in your font_dirs.

If you're not using a font_dir already, you might find it helpful to temporarily add font_dirs = { "/path/to/dir/containing/iosevka" } so that you can see what the font parser makes of the font.

Now, should Iosevka Term Light Italic work? My intent was that you should be able to specify the name in that fully qualified style, which should work with the loader that pulls from font_dirs, but if we have to resolve from core-text there may be a mismatch in the name we use to lookup, especially if we've carried out some speculative name editing to find a base family.

guswynn commented 3 years ago

Curiously {weight="Light"} seems to produce the correct glyphs, but way lighter in color?

font_with_fallback("Iosevka Term Light"),: (what I have now) image font_with_fallback("Iosevka Term"),: (to show that its actually different) image font_with_fallback("Iosevka Term", {weight="Light"}),: image

guswynn commented 3 years ago

Actually, setting an explicit font dir (font_dirs = {"/Users/azw/Library/Fonts"},) seems to have worked!

now my only font problem is tmux eating the strikethrough control character! One thing at a time!

Thanks!

wez commented 3 years ago

I think there may be an issue with the core text loader; keeping this open so I don't forget

wez commented 3 years ago

Yeah, there was an issue with how fonts were being returned from core text; I've pushed a fix for that, so you should be able to undo the font_dirs change in the nightly.

Also in the nightly: wezterm ls-fonts --list-system will show you all possible fonts and their canonical syntax, including those returned from the system.

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.