githubnext / monaspace

An innovative superfamily of fonts for code
https://monaspace.githubnext.com
SIL Open Font License 1.1
13.23k stars 215 forks source link

Font properties cause glyphs to sit strangely in many terminals #21

Open mitchellh opened 8 months ago

mitchellh commented 8 months ago

Congratulations on the launch.

I'm developing a terminal emulator so whenever any monospace font is released, the first thing I do is jump on it and see how it all looks. I was especially interested because all the features Monaspace uses (variation axes, opentype features, etc.) are supported by my terminal so I wanted to make sure everything looked good. I immediately noticed that things looked weird, and then loaded the font in a variety of other terminals and verified they look a bit weird in all of them.

Some background (you may be aware of this): terminal emulators in particular aim to fit glyphs into a cell. Descenders do not typically descend below what is traditionally the baseline. Instead, the baseline is adjusted so that descenders at most touch the bottom of the cell. For example, in a typical typesetting situation, the bottom of the "g" hangs below the line into the next line. In a terminal, the "g" sits at the bottom of the cell, but does not typically enter the cell below it.

The way these metrics are calculated somewhat varies between terminals, but a common algorithm is:

cell_height = ascent + descent + leading
cell_baseline = descent + leading

where ascent, descent, and leading are directly from the font face.

If you look at a number of popular terminal emulators (macOS in this case, but similar things happen on Linux), this causes the glyphs to sit high in the cell. I've chosen two extremely popular terminal emulators as examples below, but I'm not trying to pick on them, this happens also in other terminals:

Kitty

image

iTerm2

image

There are various rendering artifacts but just focus where glyphs sit (since the other issues are likely not caused by monaspace). Notice that the top of the "h" is touching the top of the cell. The lowest part of the "y" descender is sitting quite high in the cell as well. The "N" is well above the midline because the baseline is so high.

I'm not 100% sure this is your fault, but each of these terminals use slightly different algorithms for calculating cell metrics and these algorithms work across hundreds of other known monospace fonts of varying popularity, but seem to have issues with Monaspace. So I wanted to raise this issue and perhaps discuss what can be done to help make Monaspace work better with these terminal projects.

Thanks!

anasrar commented 8 months ago

I would like to have variant for line height like Meslo, when some terminal emulator does not have option to adjust the line height.

Finii commented 8 months ago

Duplicate #37

johnend commented 1 week ago

I have noticed that not only do the fonts sit too high but in some instances (in my case working in NeoVim within Wezterm with the cell height increased slightly) it can cause inconsistent rendering of individual characters e.g.

image The T in adjust on line 6, and the Ms on line 10. This rendering actually changes when the font is scrolled in the window by 1 cell e.g. image

Line numbers are not one different due to being relative.

[EDIT] to expand on this I raised a discussion item on the Wezterm repo and the suggested fix was to go through the hinting options available there. https://wezfurlong.org/wezterm/config/lua/config/freetype_load_flags.html?h=hinting however none of those options completely solves the problem leading me to the assumption that something in the font is causing this to happen.

So far this affects Argon, Neon and Radon (though Neon seems to be cut off at the bottom).