-
Notifications
You must be signed in to change notification settings - Fork 234
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Font properties cause glyphs to sit strangely in many terminals #21
Comments
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 |
- githubnext#21 githubnext#37 "Hanging Font": Miss configure `typo` and `hhea` value. Adjust this value will "centering" glyphs across the vertical bounding box. - githubnext#169 Probably same as above, tweaking `typo` and `hhea` does resolve the `line-height` or `leading` default to `1.2` or `120%` from the upm value. UPM = 2000 (typo/hhea)Ascenders = 1930 (typo/hhea)Descenders = -470 (typo/hhea)LineGap = 0 Total: ascender + abs(descenders) + linegap = 2400 Note that "Gcommaaccent" may be truncated in environments that have `overflow: hidden` Please see these documentation: - https://googlefonts.github.io/gf-guide/metrics.html#6-winascent-and-windescent-values-must-be-the-same-as-the-familys-tallestdeepest-ymin-and-ymax-bounding-box-values - https://googlefonts.github.io/gf-guide/metrics.html#11-the-sum-of-the-fonts-vertical-metric-values-absolute-should-be-20-30-greater-than-the-fonts-upm
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.
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!
The text was updated successfully, but these errors were encountered: