Skip to content

Some glyphs in Nerd Fonts are rendered with wrong widths #11769

Closed

Description

@benfowler

Windows Terminal version

1.12.2931.0

Windows build number

10.0.19042.0

Other Software

  • Font: CaskaydiaCove Nerd Font

Steps to reproduce

  1. Open Windows Terminal Preview with a clean configuration
  2. Obtain the "CaskaydiaCove Nerd Font" (patched stock Windows Terminal font), and install it via choco install cascadia-code-nerd-font
  3. Output the characters onto the console. I've made the attached text file to do a minimal reproduction of this issue: break_tmux_nf_glyph_broken_under_msterm.txt
    • 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
    • For more information on Nerd Font glyphs, see the Nerd Font Cheat Sheet

Expected Behavior

Correct rendering of widths of Nerd Font glyphs, as far as I can tell.

screenshot-nf-glyphs-correct-alacritty

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:

screenshot-nf-glyphs-STOCK-Cascadia-winterm

Actual Behavior

Result of outputting test text file in Windows Terminal:

screenshot-nf-glyphs-wrong-winterm

Even if the characters are 'wide' in the unpatched font, these glyphs are not rendered wide in patched ('Nerd Font') fonts.

Good (Alacritty and other terminal emulators):

bar-good-alacritty

Bad (Windows Terminal Preview):

bar-bad-windows-terminal-pre

Activity

  1. ghost added
    Needs-TriageIt's a new issue that the core contributor team needs to triage at the next triage meeting
    on Nov 16, 2021
  2. ghost added
    Needs-Tag-FixDoesn't match tag requirements
    on Nov 16, 2021
  3. DHowett commented on Nov 16, 2021

    @DHowett
    Member

    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. 😄

  4. benfowler commented on Nov 17, 2021

    @benfowler
    Author

    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:

    paste1

    but then if I immediately type some additional characters, the output character cells seem to lose sync with the cursor:

    paste2

    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.

  5. benfowler commented on Nov 17, 2021

    @benfowler
    Author

    For any passers-by, this writeup about Nerd Fonts and glyph advance behaviour is a really interesting read.

  6. benfowler commented on Nov 17, 2021

    @benfowler
    Author

    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.

  7. DHowett commented on Nov 17, 2021

    @DHowett
    Member

    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:

    image

    (Centered, rather than left-aligned, as the glyph is intended to occupy two cells. That's likely to be negotiable.)

  8. ghost closed this as completedon Nov 17, 2021
  9. ghost removed
    Needs-TriageIt's a new issue that the core contributor team needs to triage at the next triage meeting
    on Nov 17, 2021
  10. ghost added
    Resolution-DuplicateThere's another issue on the tracker that's pretty much the same thing.
    on Nov 17, 2021
  11. ghost removed
    Needs-Tag-FixDoesn't match tag requirements
    on Nov 17, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Area-FontsRelated to the fontProduct-TerminalThe new Windows Terminal.Resolution-DuplicateThere's another issue on the tracker that's pretty much the same thing.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions