Repository navigation
Arrow (➜) character in prompt is rendered small #6864
Description
Environment
Windows build number: [Version 10.0.19041.329]
Windows Terminal 1.0.1811.0
Microsoft Visual Studio Code 1.47.0
Steps to reproduce
- Open Windows Terminal
- Open
oh-my-zshwithrobbyrusselltheme (or any theme that has an arrow character) - Open Visual Studio Code
- Open its integrated terminal
Expected behavior
- They should look identical
Actual behavior
- The size of the arrow (➜) character in prompt is rendered smaller in Windows Terminal than Visual Studio Code's integrated terminal
Arrow character is smaller in Windows Terminal:
However, it looks accurate on Visual Studio Code:
Reacted by Guilherme Tod, Tesla Zhang, Bahram Hodjaev, kobe2018, Latif Sulistyo and Steel
Activity
devcrev commentedon Jul 12, 2020
Also look at the checkmark size and colors. I am using the Cascadia Mono font in the screenshots below. In both examples, on the last line, the checkmark should be dark. It is not the right color in the Windows Terminal program but it is the right color in the VS Code Terminal.
Windows Terminal Excerpt...
VS Code Terminal Excerpt...
zadjii-msft commentedon Jul 16, 2020
Michael Niksa (@miniksa) do we have an active megathread for ongoing character sizing issues? See also #6738
miniksa commentedon Jul 16, 2020
I don't think so. We keep flopping on this because I think these Emoji are ones that were retroactively converted to two-columns. We'll have to dig yet again.
However, submitters (arish, DevCrev (@devcrev)), it will immensely help the future investigator if you redirect the output from your prompts/commands to a file and attach it here. Then we can have access to the exact character stream that is causing you issues even if it takes us a while to get around to this.
DHowett commentedon Jul 16, 2020
This is because other terminals allow the arrow glyph to spill outside of its cell. It's "single-width", but rendered double-width. iTerm2 does this with the narrow emoji, as well. The character under the right half of the two-cell glyph draws on top of the right side of it. It's ugly, but effective, and people can use spaces to give the arrow/emoji room to grow.
DHowett commentedon Jul 16, 2020
I'll look for the duplicate.
devcrev commentedon Jul 16, 2020
Sure!
Output from the Windows Terminal program is in terminal.txt. Output from the VScode program is in vs_code.txt.
terminal.txt
vs_code.txt
It was a little tricky to generate these files since the command
./node_modules/.bin/eslint --initwalks the user through a series of questions. I snapshotted the captures at the moment the screens would look like they do in the screenshots I posted earlier (less the command that generated the output).You will find the two files to be the same, i.e., binary equivalents.
1 remaining item
Izolentiy commentedon Mar 4, 2022
Hello there again! If someone is facing the same problem, I recommend to use another characters:
windows logo: "\ue70f", arrow: "\uf554"
You'll get this in VS Code
in Windows Terminal
Hope it helped someone to solve their problem.
zadarmo commentedon Apr 6, 2022
You terminal is awesome! Could you please tell me how to show the branch icon before text "master" and the clock icon before time "23:15"?
Izolentiy commentedon Apr 6, 2022
Sure! branch icon: "\ue0a0", clock icon: "\uf017".
If you want to have exactly the same theme as me. You can copy it from here and maybe modify it as you want on your local machine: https://github.com/Izolentiy/ThemesForApps/tree/master/WindowsTerminal
I uploaded my theme there. I think that exists better way to share my theme, but for faster result I did this.
felipecrs commentedon Jun 14, 2022
Another example:
PS: Thanks Dustin L. Howett (@DHowett) for pointing out this issue.
zadarmo commentedon Jun 15, 2022
I‘m sorry to reply so late. But thanks! Your answer helps me a lot. Now I know they are just preset-icons of some theme.
lhecker commentedon Sep 14, 2022
237dmitry you wrote "The default console looks much better." showing
And you're right. It does look better. This is because the default console uses the font's information to determine how many cells a glyph like that takes up. But as you can imagine that is quite problematic for terminal applications, since those can't actually "see" what's on the screen. As such people have decided that all glyphs that aren't listed in the Unicode Standard Annex #11 have a width of 1 column. That way terminal applications can blindly trust the terminal where it puts text on the screen again. (See #2066 for more information.)
But why do emojis and Nerd Font icons still work correctly in other terminals? Because they use Unicode Standard Annex #11 only to determine how the cursor moves, while the text itself is still drawn according to the font's information. So for instance the Nerd Font icon U+F07B (similar to 🗀) is supposed to take up 1 column, but other terminals draw it in the original 2 column wide size, overdrawing the text that follows it (in this case the whitespace after the icon). In other words, if you take other terminals and write
"`u{f07b}xyz"it'll actually draw something like "🗀yz".Now, normally this would be easy to fix: We just check the width of Nerd Font icons, right? Unfortunately, for some reason and quite annoyingly so, the "advance width" (aka how much the font file wants the cursor to move after drawing the glyph) of those icons isn't 2 but actually 1. The Nerd Font font files simply draw half the glyph outside the 1 column wide bounding box.
So the only way to consistently get that actual width of both Emojis and Nerd Font icons, etc., is by measuring the glyph which is fairly expensive.
A thorough fix is difficult and depends on us rendering the buffer contents off of a text buffer snapshot without console lock so that we can run the expensive measurements without blocking the entire application. A immediate, partial fix is to run those measurements inside the lock anyways, but only for Nerd Font icons since those hopefully don't occur that often. I'll have to think about this some more... but I am planning to solve it this year.
ismailhkose commentedon Sep 29, 2022
I'd like to report same issue for different Unicode character.
Same issue for long arrow, "⟶", character ( U+27F6). It's rendered extremely small.
I changed font to "UbuntuMono Nerd Font" in Notepad, and pasted the character, "⟶", everything is fine with notepad.
Actual Behavior
I'd like to use long arrow in VIM to replace 'I^' character for tab indentation.
It's actually not clear even Windows terminal renders long arrow as arrow or different character. It's extremely small.
Actual behavior
Expected behavior:
NoBurpees commentedon Feb 15, 2023
In 1.15.3465 (with activated new renderer) double width glyphs are displayed "correctly".
(1.15 works)
(1.16 wrong)
Rewrite AtlasEngine to allow arbitrary overhangs (#14959)