-
Notifications
You must be signed in to change notification settings - Fork 8.5k
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
Arrow (➜) character in prompt is rendered small #6864
Comments
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. |
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), 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. |
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. |
I'll look for the duplicate. |
Sure! It was a little tricky to generate these files since the command You will find the two files to be the same, i.e., binary equivalents. |
Here are the outputs from Windows Terminal and Visual Studio Code's integrated terminal: |
Sure! branch icon: "\ue0a0", clock icon: "\uf017". |
Another example: PS: Thanks @DHowett for pointing out this issue. |
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. |
@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 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. 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. |
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. 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. |
This is practically a from scratch rewrite of AtlasEngine. The initial approach used a very classic monospace text renderer, where the viewport is subdivided into cells and each cell is assigned one glyph texture, just like how real terminals used to work. While we knew that it would have problems with overly large glyphs, like those found in less often used languages, we didn't expect the absolutely massive number of fonts that this approach would break. For one, the assumption that monospace fonts are actually mostly monospace has turned out to be a complete lie and we can't force users to use better designed fonts. But more importantly, we can't just design an entire Unicode fallback font collection from scratch where every major glyph is monospace either. This is especially problematic for vertical overhangs which are extremely difficult to handle in a way that outperforms the much simpler alternative approach: Just implementing a bog-standard, modern, quad-based text renderer. Such an approach is both, less code and runs faster due to a less complex CPU-side. The text shaping engine (in our case DirectWrite) has to resolve text into glyph indices anyways, so using them directly for text rendering allows reduces the effort of turning it back into text ranges and hashing those. It's memory overhead is also reduced, because we can now break up long ligatures into their individual glyphs. Especially on AMD APUs I found this approach to run much faster. A list of issues I think are either obsolete (and could be closed) or resolved with this PR in combination with #14255: Closes #6864 Closes #6974 Closes #8993 Closes #9940 Closes #10128 Closes #12537 Closes #13064 Closes #13527 Closes #13662 Closes #13700 Closes #13989 Closes #14022 Closes #14057 Closes #14094 Closes #14098 Closes #14117 Closes #14533 Closes #14877 ## PR Checklist * Enabling software rendering enables D2D mode ✅ * Both D2D and D3D: * Background appears correctly ✅✅ * Text appears correctly * Cascadia Code Regular ✅✅ * Cascadia Code Bold ✅✅ * Cascadia Code Italic ✅✅ * Cascadia Code block chars leave (almost) no gaps ✅✅ * Terminus TTF at 13.5pt leaves no gaps between block chars ✅✅ * ``"`u{e0b2}`u{e0b0}"`` in Fira Code Nerd Font forms a square ✅✅ * Cursor appears correctly * Legacy small/medium/large ✅✅ * Vertical bar ✅✅ * Underscore ✅✅ * Empty box ✅✅ * Full box ✅✅ * Double underscore ✅✅ * Changing the cursor color works ✅✅ * Selection appears correctly ✅✅ * Scrolling in various manners always renders correctly ✅✅ * Changing the text antialising mode works ✅✅ * Semi-transparent backgrounds work ✅✅ * Scroll-zooming the font size works ✅✅ * Double-size characters work ✅✅ * Resizing while text is printing works ✅✅ * DWM `+Heatmap_ShowDirtyRegions` shows that only the cursor region is dirty when it's blinking ✅✅ * D2D * Margins are filled with background color ❌ They're filled with the neighboring's cell background color for convenience, as D2D doesn't support `D3D11_TEXTURE_ADDRESS_BORDER` * D3D * Margins are filled with background color ✅ * Soft fonts work ✅ * Custom shaders enable continous redraw if time constant is used ✅ * Retro shader appears correctly ✅ * Resizing while a custom shader is running works ✅
Environment
Steps to reproduce
oh-my-zsh
withrobbyrussell
theme (or any theme that has an arrow character)Expected behavior
Actual behavior
Arrow character is smaller in Windows Terminal:
However, it looks accurate on Visual Studio Code:
The text was updated successfully, but these errors were encountered: