You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Some glyphs in Nerd Fonts are rendered with wrong widths #11769
nf-mdi-play (f909) and nf-mdi-stop (f9da). Character width, cell width get confused, especially depending on what character follows 'odd' character, and how many there are on a given line.
NOTE: Other glyphs, e.g. nf-custom-folder-github (e5fd) render correctly
Correct rendering of widths of Nerd Font glyphs, as far as I can tell.
This screenshot has been generated using Alacritty, but I also tried this out on Kitty and Mac Terminal (MacOS) and got the same expected behaviour.
I've added a second screenshot of Windows Terminal Preview rendering the same text file, with **Cascadia Mono"", to demonstrate how the ostensibly-correct rendering of these glyphs appears to adhere to what Windows Terminal would do with the stock (unpatched) font's glyphs for the same code points:
Actual Behavior
Result of outputting test text file in Windows Terminal:
Even if the characters are 'wide' in the unpatched font, these glyphs are not rendered wide in patched ('Nerd Font') fonts.
Curious. I bet if you select one of the NF characters that is rendering incorrectly, it will select as-if it was two columns wide (it will likely cover the 6, but when you copy it the 6 will not be present)
This is probably because of how we're batching text to push over to DirectWrite, coupled with the fact that the NF Patcher does not insert correct glyph advances. Other terminals are cell-based, rather than run-based, which makes up for deficient font data.
We're working on a new text rendering engine. I suspect it would help here, even if it made other things slightly worse.
I also believe there's a duplicate for this bug somewhere on the backlog. I'll try to find it. 😄
Trying this out -- if I immediately copy the arrow character onto the clipboard, and then paste it straight back, the cursor advances as if it occupied two cells:
but then if I immediately type some additional characters, the output character cells seem to lose sync with the cursor:
I wasn't going to mention that, but wanted to keep this report focused. Happily, it seems that this behaviour is already thoroughly understood.
I'm completely happy to close this bug report if this is already covered elsewhere.
Dustin L. Howett (@DHowett) I had noticed that the troublesome glyphs reside outside the BMP private use area (U+E000–U+F8FF), and was going to do some testing or delve into the code when time permits, in case that was a factor.
From my own testing, this doesn't appear to happen to all Nerd Font glyphs, only some. I use other code points, and the problematic ones happen to be in the Material Design icons range, per the glyph range allocations documented on this page on the NF Wiki.
Activity
DHowett commentedon Nov 16, 2021
Curious. I bet if you select one of the NF characters that is rendering incorrectly, it will select as-if it was two columns wide (it will likely cover the 6, but when you copy it the 6 will not be present)
This is probably because of how we're batching text to push over to DirectWrite, coupled with the fact that the NF Patcher does not insert correct glyph advances. Other terminals are cell-based, rather than run-based, which makes up for deficient font data.
We're working on a new text rendering engine. I suspect it would help here, even if it made other things slightly worse.
I also believe there's a duplicate for this bug somewhere on the backlog. I'll try to find it. 😄
benfowler commentedon Nov 17, 2021
Thanks! That's indeed exactly what happens.
Trying this out -- if I immediately copy the arrow character onto the clipboard, and then paste it straight back, the cursor advances as if it occupied two cells:
but then if I immediately type some additional characters, the output character cells seem to lose sync with the cursor:
I wasn't going to mention that, but wanted to keep this report focused. Happily, it seems that this behaviour is already thoroughly understood.
I'm completely happy to close this bug report if this is already covered elsewhere.
benfowler commentedon Nov 17, 2021
For any passers-by, this writeup about Nerd Fonts and glyph advance behaviour is a really interesting read.
benfowler commentedon Nov 17, 2021
Dustin L. Howett (@DHowett) I had noticed that the troublesome glyphs reside outside the BMP private use area (U+E000–U+F8FF), and was going to do some testing or delve into the code when time permits, in case that was a factor.
From my own testing, this doesn't appear to happen to all Nerd Font glyphs, only some. I use other code points, and the problematic ones happen to be in the Material Design icons range, per the glyph range allocations documented on this page on the NF Wiki.
zadjii-msft commentedon Nov 17, 2021
Maybe one of:
DHowett commentedon Nov 17, 2021
Yep, this is definitely a /duplicate of #6864. Ben Fowler (@benfowler), thanks for all the additional info!
For the record, here's what it looks like in the new rendering engine:
(Centered, rather than left-aligned, as the glyph is intended to occupy two cells. That's likely to be negotiable.)