Open mitchellh opened 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.
Duplicate #37
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.
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.
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).
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:
where
ascent
,descent
, andleading
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
iTerm2
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!