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

Dashed horizontal line (---) when using TUI tools and JetBrainsMono NF #13794

Closed
AdalZanabria opened this issue Aug 20, 2022 · 13 comments
Closed
Labels
Area-Rendering Text rendering, emoji, complex glyph & font-fallback issues Issue-Bug It either shouldn't be doing this or needs an investigation. Needs-Attention The core contributors need to come back around and look at this ASAP. Needs-Tag-Fix Doesn't match tag requirements Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release.

Comments

@AdalZanabria
Copy link

Windows Terminal version

Windows Terminal 1.14.1962.0. Also tested in Windows Terminal Preview 1.15.2002.0. Both tested with AtlasEngine off and on.

Windows build number

10.0.19044.0

Other Software

Any TUI tool with horizontal lines, for example:

  • Midnight Commander
  • Ranger
  • Neofetch
  • some special prompts using ---

Steps to reproduce

Open any Terminal User Interface tool that uses horizontal lines as separators like Midnight Commander, Ranger, neofetch, etc. While using the JetBrainsMono NF font.

Expected Behavior

To horizontal lines to render as single continuous line.

The following are examples of the same font and same size in different terminals rendering with the expected behavior:

VS Code Integrated Terminal:
vscode

Wezterm:
wezterm

Hyper:
hyper

Actual Behavior

Horizontal lines render dashed, as spaced - - - -

Windows Terminal:
wt

Windows Terminal Preview:
wtp

Not sure what can be causing this since the same exact font seems to be working on other terminals just fine, I also tested other NerdFonts like FiraCode NF in both Windows Terminal and Windows Terminal Preview and it displays the horizontal lines correctly. I thought that maybe because it was .ttf instead of .otf? But I installed FiraCode NF as .ttf and it worked fine with the lines.

Again, I also tried the Atlas Engine on are off with the same result.
I also made sure to install the versions which don't state "Mono" as a sufix in the font file name since NerdFonts specify that they could cause problems rendering ligature characters in favor of monospacing them. I did the same with FiraCode NF and Fira's horizontal lines are working while Jetbrains not.
Again this is not a problem only for Midnight Commander, it happens with every TUI Tool that uses horizontal lines or special prompts like the ones used with zsh.
I downloaded the font from nerdfonts Github repository which was rebuilt yesterday, but again the same font is working fine in other terminals.

@AdalZanabria AdalZanabria added the Issue-Bug It either shouldn't be doing this or needs an investigation. label Aug 20, 2022
@ghost ghost added Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting Needs-Tag-Fix Doesn't match tag requirements labels Aug 20, 2022
@237dmitry

This comment was marked as off-topic.

@AdalZanabria

This comment was marked as off-topic.

@237dmitry

This comment was marked as off-topic.

@AdalZanabria

This comment was marked as off-topic.

@zadjii-msft
Copy link
Member

@lhecker Does this look like the kinda thing that would have been fixed alongside the other PL fixes for atlas engine in 1.16?

@lhecker
Copy link
Member

lhecker commented Aug 22, 2022

@AdalZanabria Can you please link the exact font file which works in VS Code but doesn't work in Windows Terminal? I tried this one but it works in neither application the way you describe it. I'd also need to know how you got ligatures working in the VS Code terminal. Support for it has been broken since about 2017...

I've set "editor.fontLigatures": true in VS Code and while I get nice lines in the editor:
image

I don't get any in the terminal:
image

@zadjii-msft zadjii-msft added the Needs-Author-Feedback The original author of the issue/PR needs to come back and respond to something label Aug 22, 2022
@AdalZanabria
Copy link
Author

@AdalZanabria Can you please link the exact font file which works in VS Code but doesn't work in Windows Terminal?

I'm using that exact same one, however it seems like the box drawings aren't ligatures, since just as you mention ligatures don't work:
ligatures

But it still can render a continuous line:
mc-vscode

I changed the font to glorious Comic Sans MS, a font which obviously doesn't support ligatures and it can still render continuous lines just fine:
comic_sans

While taking this screenshots and checking the integrated terminal setting, I had a finding, a setting called "Custom Gyphs" which states it draws custom glyphs for block elements and box drawing characters, this is a screenshot with it on:
custom_glyphs_on

And this is a screenshot with it turned off:
custom_glyphs_off

So that's what's making the magic.
Now, going back to Windows Terminal, it's weird that it also uses "Custom Glyphs" (Going by VS Codes nomenclature)
But only for vertical lines, not horizontal... (while using JetBrainsMono NF)
no_glyphs_vertical

But when using another font such as FiraCode NF
FiraCode_NF
It does render both vertical and horizontal custom glyphs, so it doesn't sound like a custom glyphs problem...

And this is the exact same font (JetBrainsMono NF) in wezterm without any custom glyphs issues:
wezterm

So it's not a problem with the font, it's just when both are together.

@ghost ghost added Needs-Attention The core contributors need to come back around and look at this ASAP. and removed Needs-Author-Feedback The original author of the issue/PR needs to come back and respond to something labels Aug 22, 2022
@lhecker
Copy link
Member

lhecker commented Aug 22, 2022

I see... I thought the issue was with actual dashes (U+002D "-"), but those sure seems like box characters (U+2500 "─"). In that case this issue will be fixed in 1.16 when the new text renderer / AtlasEngine is enabled. The specific PR that fixed this is #13549. 1.16 will support all "block element" and "box drawing" characters as well as the classic powerline glyphs (source).

@lhecker lhecker closed this as completed Aug 22, 2022
@lhecker lhecker added Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release. Area-Rendering Text rendering, emoji, complex glyph & font-fallback issues labels Aug 22, 2022
@AdalZanabria
Copy link
Author

issue will be fixed in 1.16 when the new text renderer / AtlasEngine is enabled

Is it an updated version from the the one that can be used right now with "experimental.useAtlasEngine": true ?
Because I already tested with that and the same problem persists.

@lhecker
Copy link
Member

lhecker commented Aug 22, 2022

#13549 hasn't been released yet, but will be soon. You can subscribe to that pull request to get notified once it's been released. 🙂

@AdalZanabria
Copy link
Author

Ok, I'll do that. Thank you very much!

@ofek
Copy link
Contributor

ofek commented Jan 25, 2023

This is still broken for me on the latest preview release using the font CaskaydiaCove Nerd Font

@ofek
Copy link
Contributor

ofek commented Jan 25, 2023

Actually upgrading the font in addition to using the latest release fixes the issue

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-Rendering Text rendering, emoji, complex glyph & font-fallback issues Issue-Bug It either shouldn't be doing this or needs an investigation. Needs-Attention The core contributors need to come back around and look at this ASAP. Needs-Tag-Fix Doesn't match tag requirements Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release.
Projects
None yet
Development

No branches or pull requests

5 participants