The baseline position is a bit high

[frostming]

Not sure if I am misconfigured on something, the font characters go a bit high in a line, both in Kitty and VSCode:

[Finii]

I would guess that is the result of the line gap. You can correct that with font-line yourself.
The effect depends on your terminal, I'd say there is nothing wrong with having a line gap.
Some terminal split the gap evenly top and bottom, some might have the full gap on the top.

If you do a Nerd Font patch it will (has to) distribute the gap for you:

[mitchellh]

Thanks @Finii that's great insight. Looking at the way my terminal (and many others) calculate cell heights and baselines, I think I was handling the leading metric incorrectly. In CoreText, that's CTFontGetLeading. Previously, my cell metrics used:

cell_height = ascent + descent + leading
cell_baseline = height - ascent

The issue is this doesn't properly distribute the leading value equally across top and bottom for terminal cell grids. This doesn't cause an issue in many fonts because at least of the few I tested (Monaco, JetBrains Mono, Berkeley, Fira) they have a zero leading value. But Monaspace has a non-zero leading value.

I'm not 100% sure this is correct, but I changed the formula to the following instead, and the results look much better:

cell_height = ascent + descent + leading
cell_baseline = height - (ascent + (leading / 2))

This distributes the leading equally across the top/bottom by adjusting the baseline.

[onur-o7]

Hi If you are using Kitty modify_font baseline -2 option does the job for me

[Finii]

@mitchellh Additionally the problem is of course how to handle the three different sets of metrics in fonts that contradict themselves ;-)

In principle the whole concept of a line gap does not really resonate with terminal cells. Most terminal fonts have a zero gap, and NerdFonts removes any gap of sourcefonts. Why have a gap?

Haralambous has not much to say in Fonts & Encodings:

Here code done long ago, it even takes use-typo-metric into account 🙄

       # Step 1
        # There are three ways to discribe the baseline to baseline distance
        # (a.k.a. line spacing) of a font. That is all a kuddelmuddel 
        # and we try to sort this out here
        # See also https://glyphsapp.com/learn/vertical-metrics
        # See also https://github.com/source-foundry/font-line
        (hhea_btb, typo_btb, win_btb, win_gap) = get_btb_metrics(self.sourceFont)
        use_typo = self.sourceFont.os2_use_typo_metrics != 0

[1] https://glyphsapp.com/learn/vertical-metrics
[2] https://github.com/source-foundry/font-line

[frostming]

Thanks for the reply! I managed to fix this by patching with nerd font.

Hi If you are using Kitty modify_font baseline -2 option does the job for me

This should also work.

[ryankask]

I'm seeing this issue in emacs. Does anyone know of a solution?

[PMunch]

@ryankask, it's terminal dependent. Basically Monaspace uses some font properties not typically used by monospace fonts and many terminals are not handling it quite right. There was a fix for the Kitty terminal named above which worked great for me, see if you can find something similar for your terminal or open an issue with it.

[ryankask]

Thanks! This is for emacs rather than a terminal but looking at Mitchell's comment and searching for CTFontGetLeading I wonder if there is an issue in this file: https://github.com/emacs-mirror/emacs/blob/e81e625ab895f1bd3c5263f5b66251db0fd38bd6/src/macfont.m#L2739

I'm curious if any emacs users on Windows or Linux see the same baseline positioning issue.

[PMunch]

Don't you run Emacs from within a terminal? Or is this some kind of weird graphical Emacs? I'm not very familiar with how you run it, I always assumed it was like Vim.

[iodic]

Hey guys, I am seeing a similar issue in Sublime Text (and Sublime Merge):

I can tweak it in the editor to achieve equal spacing (but the caret not aligning with the line highlight is killing me):

It looks a bit worse in Sublime Merge:

But it can be helped by adding these two properties when editing the settings file (you may need to adjust the padding values for the font size you are using):

"line_padding_top": 4,
"line_padding_bottom": -1,

And it ends up looking better:

I know this is not perfect but it might help if someone else wants to try out the new fonts. :)

[jasbrg]

@PMunch most Emacs users run the application graphically[1].

@ryankask I have the same issue on Emacs 30.0.50 & macOS 14.4.1. Did you find any work around?

[1]https://emacssurvey.org/2020/

[Finii]

Maybe just push the font through font-line? https://github.com/source-foundry/font-line

Which's report looks more or less ok:

=== /home/ujastrow/git/nerd-fonts/src/unpatched-fonts/Monaspace/Neon/MonaspaceNeon-Regular.otf ===
Version 1.000 (Monaspace Neon)
SHA1: fbede302d26cec201f6727c69cef68eb33d6843a

::::::::::::::::::::::::::::::::::::::::::::::::::
  Metrics
::::::::::::::::::::::::::::::::::::::::::::::::::
[head] Units per Em:   2000
[head] yMax:           1951
[head] yMin:          -760
[OS/2] CapHeight:      1460
[OS/2] xHeight:        1027
[OS/2] TypoAscender:   1565
[OS/2] TypoDescender: -435
[OS/2] WinAscent:      1878
[OS/2] WinDescent:     522
[hhea] Ascent:         1565
[hhea] Descent:       -435

[hhea] LineGap:        400
[OS/2] TypoLineGap:    400

::::::::::::::::::::::::::::::::::::::::::::::::::
  Ascent to Descent Calculations
::::::::::::::::::::::::::::::::::::::::::::::::::
[hhea] Ascent to Descent:              2000
[OS/2] TypoAscender to TypoDescender:  2000
[OS/2] WinAscent to WinDescent:        2400

::::::::::::::::::::::::::::::::::::::::::::::::::
  Delta Values
::::::::::::::::::::::::::::::::::::::::::::::::::
[hhea] Ascent to [OS/2] TypoAscender:       0
[hhea] Descent to [OS/2] TypoDescender:     0
[OS/2] WinAscent to [OS/2] TypoAscender:    313
[OS/2] WinDescent to [OS/2] TypoDescender:  87

::::::::::::::::::::::::::::::::::::::::::::::::::
  Baseline to Baseline Distances
::::::::::::::::::::::::::::::::::::::::::::::::::
hhea metrics: 2400
typo metrics: 2400
win metrics:  2400

[OS/2] fsSelection USE_TYPO_METRICS bit set: True

I guess the problem is your client that ignores can not work with the GAP value.

Nerd Fonts removes the gap and puts it half on top and half on bottom of the ordinary 'cell', which looks ok-ish I guess:

$ fontforge font-patcher src/unpatched-fonts/Monaspace/Neon/MonaspaceNeon-Regular.otf --debug 2 2>/dev/null 
Nerd Fonts Patcher v3.2.1-3 (4.13.1) (ff 20230101)
DEBUG: Naming mode 1
DEBUG: Monospace check: Panose is invalid ([0, 0, 0, 0, 0, 0, 0, 0, 0, 0]); glyph-width-mono True
INFO: Setting Panose 'Family Kind' to 'Latin Text and Display' (was 'Any')
INFO: Setting Panose 'Proportion' to 'Monospaced' (was 'Any')
INFO: Redistributing line gap of 400 (200 top and 200 bottom)
DEBUG: Final font cell dimensions 1240 w x 2400 h
Adding 188 Glyphs from Seti-UI + Custom Set
╢████████████████████████████████████████╟ 100%
...

.....

Oh just notices I wrote the same already some time ago. Seemed to not help people.
Just take the font-line tool and redistribute the gap yourselves. That is not hard.

In principle I would recommend the font designers to remove the gap from Monaspace as different clients unfortunately have different ideas how to handle it.