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.

Interestingly, switching the font back and forth actually fixes the issue for anything that has already been printed.

Huh. Good catch!

What is "set_color"?

I have no problem doing it manually (in TCSH).

It's a function in Fish that makes colorizing output a little easier. And not every character crosses over into the next spot, I found that '0' did it a lot.

Everything seems to be fine:

Huh. I've noticed that any action that would cause a re-render like changing the font or font size fixes the issue for anything that's already been printed.

Thanks. I was using Consolas. I switch to Cascadia Code and tried a few characters that are tycically wide, and a few font sizes. I'm still OK (though the lowercase w's are a bit weird).

I believe this only happens when you're changing colors. So in most cases you wouldn't see it at the end of a line, but I'm guessing the OP is actually writing out text with a black background while the rest of the screen is using the default color (which just happens to be the same value as black), so there is actually an invisible transition from black to default where the characters get clipped.

I'm was aware this could happen when I implemented italics, but I didn't think there was much we could do about it.

That makes sense, except I'm not changing the background color as far as I know

Hmm... you're right. The test case you did with the escape sequence is clearly using the default background, so it can't be that. I'm not sure what is triggering it for you then. I wonder if the acrylic background is the issue.

Turning off acrylic didn't fix the issue ... but switching my anti-aliasing mode from "cleartype" to "grayscale" did. It seems like that's what's causing it.

this only happens when you're changing colors

May be this is "fish"-behavior

I've confirmed it happens in bash as well

switching my anti-aliasing mode from "cleartype" to "grayscale" did. It seems like that's what's causing it.

Yep, that's it. I can reproduce it now too.

So, when we render individual "runs" of text we clip the rendering region to the estimated space to avoid characters overhanging their boxes. The italics and the spaces are logically two units . . . at first.

I suspect that when we re-render the line containing the italic text (in response to a selection, cursor blink, etc.), we decide that the italic text plus the spaces after it are a single run and don't clip it. Probably due to our "identical visual representation for space characters" "optimization" ;P

@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'm having the same issue, which I notice only with neovim so far and fonts without italic variant

I'm also seeing this issue in vim/neovim regardless of "antialiasingMode": "cleartype" or "antialiasingMode": "grayscale". Especially noticeable when 0 or { are the ending characters.

Although, grayscale seemingly fixes it in the shell, zsh in this case.

echo -e "\e[3m foo {{{ \e[23m"

Windows Terminal Preview
Version: 1.8.1032.0

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)

I know that italics usually goes out of their bounding box in the font design, and turning on full-hinting like windows does will force the font to strictly follow the the box guide, which might cut some characters off..

But how does that explain characters without the error though.. That's what confuses me..

Caption: Italic goes off bounding box, which make full-hinting system like windows terminal likely to cut off:

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.

Would there be a way to fix this? I mean it sounds like we can fix this by making the behavior of clipping more consistent (like always encompasses some of the following space characters until a non-italic glyph, for example)..

I have no idea how hard it is to implement the functionality though

Any updates on this? Literally the ONLY issue I have with windows terminal is this!

Nope. We'll make sure to update this thread when there is. In the meantime, might I recommend the Subscribe button? That way you'll be notified of any updates to this thread, without needlessly pinging everyone on this thread ☺️

I have the same problem when using Neovim with WSL2 and Windows Terminal

For me, using Inconsolata (Nerd Font version), I get black boxes, presumably where the next character is supposed to be..?

Cascadia Code does tend to do what is mentioned above and clips text.

@Pranav-Badrinathan this is because the Italic variant of your font has a significantly smaller width than the Roman variant. That's actually a hole that was introduced to make up for the accumulated missing width.

Yeah, this is really more a variant of #10678, only kind of in reverse. I'm assuming the atlas renderer should fix this.

...Italic variant of your font has a significantly smaller width than the Roman variant. That's actually a hole that was introduced to make up for the accumulated missing width.

Makes sense. 1 to 2 pixels slimmer in Italics, and as you said that causes it to freak out a bit when the sentence gets long enough, by the time which the character is quite far behind. 😅

Surprising, as the font is monospace, and I thought that they were supposed to remain the same size regardless formatting... Oh well. Glad to see that this issue is set to be resolved this year!

has anyone has a solution for this? it is because bold font is showing as a regular font and not being bolded