Skip to content
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

Open
mitchellh opened this issue Nov 10, 2023 · 2 comments · May be fixed by #227
Open

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

mitchellh opened this issue Nov 10, 2023 · 2 comments · May be fixed by #227

Comments

@mitchellh
Copy link

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
Copy link

anasrar commented Nov 10, 2023

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
Copy link
Contributor

Finii commented Nov 11, 2023

Duplicate #37

ottta added a commit to ottta/monaspace that referenced this issue May 26, 2024
- 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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: No status
Development

Successfully merging a pull request may close this issue.

3 participants