terminal: Italics & Bold not rendering properly if they are the final character - text looks "cut off"
Environment
Windows build number: [Version 10.0.19042.844]
Windows Terminal version: 1.6.10571.0
Any other software?
Ubuntu using WSL 1
Fish Shell
Steps to reproduce
Print any italic text to the terminal
Expected behavior
All characters should be italicized and fully visible.
Actual behavior
The last character before a newline is cut-off where the italic character would bleed into the next character. Note this occurs when using both Cascadia Code and FiraCode in my testing.
After further testing, we’ve determined that the issue is related to the cleartype antialiasing setting. Using grayscale eliminates the issue.
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Reactions: 23
- Comments: 58 (13 by maintainers)
Commits related to this issue
- Implement cell size customizations (#14255) Does what it says in the title. After this commit you can customize the height and width of the terminal's cells. This commit supports parts of CSS' `<le... — committed to microsoft/terminal by lhecker a year ago
- Disable italics in nvim Windows terminal has a font rendering bug for the last character in a line if it is italic. This issue claims it's resolved, but it is not: <https://github.com/microsoft/term... — committed to spenserlee/.dotfiles by spenserlee a year ago
I’m having the same issue, which I notice only with neovim so far and fonts without italic variant
@DHowett So for me in the shell (fish) and on Ubuntu 20.10 it is fine
But in Neovim comments that are italic has this issue for some reason
I kinda like the idea of leaving this open for now. It will likely make it easier for those trying to see if this problem is reported and being looked. People sometimes don’t read the whole thread (I know, not our problem), and may think that the issue was closed because it was resolved.
This is the setting I have enable already to even show these fonts with a bold and italic style. It is what actually made me aware of the problem.
Here is a screenshot of an example for me where every single character (with a big enough bounding box for it to be noticeable) is cutoff. This is honestly the main reason I am still using Alacritty over WT.
This is still a pain for me. It’s the only reason I’m not using Terminal as my daily driver.
I’m also seeing this issue in vim/neovim regardless of
"antialiasingMode": "cleartype"or"antialiasingMode": "grayscale". Especially noticeable when0or{are the ending characters.Although,
grayscaleseemingly fixes it in the shell, zsh in this case.echo -e "\e[3m foo {{{ \e[23m"For text rendering with grayscale antialiasing this would mostly work, apart from an uneven appearance when glyphs do intersect. This is the approach I would choose if I had to make this change in the near-ish future, because it provides 80% of the value (overlapping glyphs mostly appear to work) for 20% of the cost (only a minor performance impact). If ClearType is enabled I’d probably force glyphs into the cell grid the way it works now, due to the lack of an alpha channel for ClearType glyphs.
But in either case this does require a non-trivial amount of work (due to the bin packing with conservative memory management & quad layout for each glyph) and and I still need to work on a lot of other rendering improvements which IMO add just as much value to Windows Terminal (looking at you, sixel support in AtlasEngine, our 4th biggest issue). Until then I’m hoping that the new cell-fitting algorithm (#13549) which ships in 1.16 next week improves the situation around italic/bold glyphs so much so that it’s far less of an issue for most users, most of the time.
Edit: The cell-fitting thing didn’t work out. 🥲
might I add that the behavior is not consistent though, on certain lines the last character will not be cut out… while on some it will be?..
Windows Terminal version (or Windows build number)
10.0.19042.1052
Other Software
Ubuntu WSL, using Vim inside the terminal
Font Used
Ubuntu Mono (which has true italic)
Everything seems to be fine:
Yep, that’s it. I can reproduce it now too.
Hey this might have been fixed by #14959. I haven’t been following this thread as closely, but I’m pretty sure this thread ended up being one of the more central premises of that approach.
Talking with @lhecker, there’s still the chance that text will be cut off on the right side of the window, by the margins, but that seems like a much smaller subset of this thread.
@lhecker If we’re going to force the cells to be wide enough to completely fit italic characters, I suspect that’s going to make the letter spacing unnecessarily large for quite a few fonts. That will be particularly annoying for users that aren’t even using italics.
I thought at one point that you had planned to allow characters to overflow their cell, which I assumed would largely solve this problem (at leat if we’re also rendering the background in a separate pass - I’m not sure if that’s true yet).
I can’t say for definite that’s what everyone else does, but I know at least some terminals do something like this. For example this is a screenshot from Mintty rendering italics with the background changing between characters.
Mark and the annoying issue is still there…
@djdv I was referring to the user that was getting black boxes at the end of the line because their italic font was narrower than the regular variant (https://github.com/microsoft/terminal/issues/9381#issuecomment-1004445152).
Sometimes terminal’s text run splitter chooses to end the run at the last character and clip to the bounding box, and sometimes it encompasses one or more of the following space characters. When it chooses to include the spaces, the clip extends to cover those cells and doesn’t truncate the last glyph.