Font rendering of ligatures (and possibly other features?) is sometimes inconsistent

[nerdo]

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

macOS

Which Wayland compositor or X11 Window manager(s) are you using?

macOS Sonoma 14.2.1 (23C71)

WezTerm version

20240127-090133-2a8bdfa6

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

I mentioned this in another issue because I thought I was having the same issue originally but it seems like a separate issue altogether.

I have encountered some odd font rendering issues. When and where they happen seems to be very inconsistent so it's a little bit difficult to describe in words, but for the most part it seems like rendering ligatures is inconsistent.

Variations I've encountered:

• Parts of a ligature appear correct, but the entire thing seems to occupy the wrong horizontal or vertical space
• Fonts sometimes shift vertically slightly out of the blue
• Underscores sometimes disappear (might be a symptom of the above)

Any and/or all of these might occur in different places in the same screen.

Here's a screenshot from a neovim editing session to illustrate:

Notice the ->'s on the lines where $factory->define is.

The first line renders correctly. I have a freely available font Caskaydia Cove Nerd Font Mono which has a ligature for -> to turn it into a connected arrow.

However, if you look at the other two instances of the same exact text, they are rendered incorrrectly. It appears as if the ligature is there, but it's not taking up the same space.

Also notice all of the fat arrows => are also ligatures, but they two characters making it up don't line up properly so there is a stair step effect.

Originally posted by @nerdo in https://github.com/wez/wezterm/issues/3774#issuecomment-1913138586

To Reproduce

I don't really know how to reproduce it.

It seems to happen randomly.

Configuration

local wezterm = require("wezterm") return { disable_default_key_bindings = true, adjust_window_size_when_changing_font_size = false, enable_tab_bar = false, front_end = "OpenGL", font = wezterm.font("CaskaydiaCove Nerd Font Mono"), font_size = 16, line_height = 1.6, color_scheme = "Argonaut", colors = { cursor_bg = "#800500", cursor_fg = "#eacecd", }, -- make both left and right alt behave in the same, normal, way -- https://wezfurlong.org/wezterm/config/keyboard-concepts.html?highlight=right%20option#macos-left-and-right-option-key send_composed_key_when_left_alt_is_pressed = false, send_composed_key_when_right_alt_is_pressed = false, keys = { { key = "v", mods = "CTRL|SHIFT", action = wezterm.action({ PasteFrom = "Clipboard" }) }, { key = "=", mods = "CTRL", action = "IncreaseFontSize" }, { key = "-", mods = "CTRL", action = "DecreaseFontSize" }, { key = "0", mods = "CTRL", action = "ResetFontSize" },

	-- MacOS keybindings
	{ key = "c", mods = "CMD", action = wezterm.action.CopyTo("ClipboardAndPrimarySelection") },
	{ key = "v", mods = "CMD", action = wezterm.action.PasteFrom("Clipboard") },
	{ key = "m", mods = "CMD", action = "Hide" },
	{ key = "q", mods = "CMD", action = "QuitApplication" },
	{ key = "0", mods = "CMD", action = "ResetFontSize" },
	{ key = "=", mods = "CMD", action = "IncreaseFontSize" },
	{ key = "-", mods = "CMD", action = "DecreaseFontSize" },
},

}

Expected Behavior

No response

Logs

No response

Anything else?

I've tried tinkering with various font and rendering settings and various different fonts. Sometimes the problems appear to go away for a little while but any workarounds I've tried so far have been red herrings, as the issues always seem to recur later.

Prior to writing this, I was using the stable version of wezterm and updated to the nightly.

At first glance, everything appeared to be working great, but when I scrutinized the same screen I had open in the screenshot, I found different artifacts being expressed this time:

Note the text $faker on the highlighted line towards the bottom that reads $factory->state(App\Concert::class, 'published', function ($faker) {. This appears to render correctly here, but in the next function, and even the first function above, there are several artifacts on the letter a where it seems like it is vertically pushed down a pixel or so making it appear as if the bottom of the letter is cut off.

I think this artifact expresses itself in other areas of this screen, like the f in faker, too, but it's hard to tell because it's so subtle on letters where there's no clear bottom.

[wez]

Try setting:

config.freetype_load_flags = 'NO_HINTING'

[nerdo]

At first glance, like before (see https://github.com/wez/wezterm/issues/3774#issuecomment-1852663247 and https://github.com/wez/wezterm/issues/3774#issuecomment-1857163595) it does seem to correct it.

I'll give it a few days and see if I notice any more issues.

[wez]

I've made NO_HINTING the default in current nightly builds in 616b218e328dd47e859beddc251c1980c49358a9

[nerdo]

Thanks wez.

Ligatures, so far, appear better, but today, I'm seeing weird vertical rendering of the letter s today.

This is often how the problem manifests btw. Today it's this character, tomorrow, it's something else. Or even from screen to screen things can sometimes shift, so I don't think I always catch it happening right away.

Notice how the s on the line function user_can_view_a_published_concert_listing() looks a bit... vertically squashed?

Then a few lines down, it appears to have the correct height, but its baseline shifted down a pixel or two... actually, yeah, in the word states on the line $concert = factory(Concert::class)->states('published')->create([, it looks like the two s's are rendered slightly differently.

The same artifact shows up on $this->visit('/concerts/' . $concert->id);

This might be a separate issue but it seems related. I can open a new issue if you think that's best?

FYI After reading your last comment, and before posting this, I updated to wezterm 20240128-202157-1e552d76 and kept my config the same as shown here.

[rgruyters]

I have still issues with it with the latest nightly version, 20240130-221529-1479c7be aarch64-apple-darwin.

I have this issue only when using Monaspace font with harfbuzz_features set. Without the harfbuzz_features it looks fine.

(with harfbuzz_features set)

UPDATE: issue is still there when harfbuzz_features is disabled. Don't know if this is a font or Wezterm issue.

[rgruyters]

Small update on this matter. The issue is only shown on a external monitor. I have it set to 2560x1440 (default for my monitor) resolution without HiDPI. When set to a smaller resolution, with HiDPI support, or use my Macbook Pro screen it shows all fine and perfect. No drunken letters or cutoffs.

[7moodDxB2004]

Hi all, I had the same issue on windows, I use fullscreen mode which might have an effect. The solution for me was to experiment with the font_size and line_height, and setting them to fractional numbers, here's an example for the difference between font_size 12.0 (1st image), 12.8 (2nd image), and 13.0 (3rd image), all while line_height is 1.1:

Note: you can see, when font_size is set to 12.8, all of these characters are aligned, this is really noticeable in line 21 window_decorations = 'INTEGRATED_BUTTONS|RESIZE',

if you want a change that will have a minimal impact on the appearance, then change line_height, I had it at 1.1, font_size at 12.0 and had this issue, then changed it to 1.08, and it was fixed, hope this helps.

[rgruyters]

Thanks @7moodDxB2004 for these findings. I also noticed that this issue doesn't exist when using JetBrains Mono font.

I have set font_size: 15.0 and line_height: 1.55 and my issues are gone.

Is there a minimum font size and line height for each font?

[7moodDxB2004]

You're right about JetBrains Mono, I use the nerd font version I installed on windows, normally this problem doesn't exist, I think when I lowered the font_size and line_height in wezterm, this issue started, even with the normal JetBrains Mono.

As for the minimum, I don't think there's a minimum, I tried font_size = 0.02 and line_height = 0.02 and it still worked, but characters were dots, if that's what you mean.

I think when you see this issue, it means the line_height is more than the height of the row and from my understanding, rows and columns can't have a fractional value. If this is the case, then finding a way to detect this issue and making the font change only when line_height == row height is the ideal solution, but this is asking too much, and I don't know rust enough to contribute.

[my4ng]

I have experienced a similar issue with Caskaydia Cove at font size 16.0 (and some larger size, e.g. 19, 20, 21, 22): Setting freetype_load_flags = "NO_HINTING" improves it, but there are still some artifacts ('bumps' between characters) and does appear to be more 'blurry': My current workaround is tweaking the font size to 16.5 with hinting: