Italics & Bold not rendering properly if they are the final character - text looks "cut off"

[Nosamdaman]

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.

[Nosamdaman]

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

[zadjii-msft]

Huh. Good catch!

[vefatica]

What is "set_color"?

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

[Nosamdaman]

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.

[237dmitry]

Everything seems to be fine:

[Nosamdaman]

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.

[vefatica]

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).

[j4james]

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.

[Nosamdaman]

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

[j4james]

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.

[Nosamdaman]

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.

[237dmitry]

this only happens when you're changing colors

May be this is "fish"-behavior

[Nosamdaman]

I've confirmed it happens in bash as well

[j4james]

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.

[DHowett]

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

[Antonio-Bennett]

@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

[xbb]

I'm having the same issue, which I notice only with neovim so far and fonts without italic variant

[Gee19]

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

[chrisdcao]

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)

[chrisdcao]

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:

[DHowett]

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.

[chrisdcao]

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

[aprowe]

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

[zadjii-msft]

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 ☺️

[Rz-Rz]

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

[Pranav-Badrinathan]

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.

[DHowett]

@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.

[j4james]

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

[Pranav-Badrinathan]

...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!

[bryant-the-coder]

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

[wespiard]

This is still a pain for me. It's the only reason I'm not using Terminal as my daily driver.

[djdv]

https://github.com/microsoft/terminal/issues/9381#issuecomment-1004448904

Yeah, this is really more a variant of https://github.com/microsoft/terminal/issues/10678, only kind of in reverse. I'm assuming the atlas renderer should fix this.

For what it's worth, at least the current version (87f5034db1eb0102358d05eeff82ebcc8032c9be) does not seem to fix this. In addition, the issue seems to apply to each character in Atlas, rather than just the last. Not sure if this has something to do with what appears to be glyph weight and kerning differences between the rendering engines.

Above is the default engine (using ClearType antialiasing), below is Atlas: Which almost turns PowerShell into a 🌸FlowerShell.

Not sure if this belongs in https://github.com/microsoft/terminal/issues/9999 as well or not.

---

Extra context I'm using a (14-point) NerdFonts patched PragmataPro, with this from my $PROFILE:

$Icon = "舘"
Write-Host "$Icon `e[3mPowerShell $($PsVersionTable.PSVersion)`e[0m"

[j4james]

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

For what it's worth, at least the current version (87f5034) does not seem to fix this.

@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).

[Acceyuriko]

I have the same issue when I use neovim.

Environment:

Windows Terminal Version: 1.12.10983.0
Font: CaskaydiaCove NF
Antialiasing: ClearType

[mrbeardad]

How about to use the italic style font in the font family instead of changing the inclination of font?

[DHowett]

How about to use the italic style font in the font family instead of changing the inclination of font?

Terminal automatically does this if the font is authored correctly. :)

[jiashun0011]

I have the same issue when I use neovim.

Environment:

Windows Terminal Version: 1.12.10983.0
Font: CaskaydiaCove NF
Antialiasing: ClearType

I have the same issue too.

[mrbeardad]

How about to use the italic style font in the font family instead of changing the inclination of font?

Terminal automatically does this if the font is authored correctly. :)

My fault, I have edited wrong weight for my italic font info. BTW, does wt support bold font?

I'm 100% sure my bold font information is correct, because vscode could render it correctly.

[DHowett]

Yes, you'll want to set this setting:

[mrbeardad]

I'm sorry that it does not work for me. #13150

[reaz1995]

i tryed to fix it in many ways, changing font to this one seems working: https://github.com/sainnhe/icursive-nerd-font/tree/master/Fira%20Code%20iCursive%20S12

[wespiard]

Yes, you'll want to set this setting:

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.

[jiashun0011]

Mark and the annoying issue is still there...

[yueyingjuesha]

Overall workflow blocked still waiting for these issues to be fixed

[miversen33]

I'm noticing this issue regardless of the text antialiser I am using (I tried Grayscale, ClearType and Alisased). Another interesting thing I noticed, this issue is only present on one of my machines. My other (using an identical profile) is not experiencing the same issue.

I have attached the profile as well as whatever info I can provide about the terminal for each machine not-broken-italics-settings.txt broken-italics-settings.txt (Note, I had to upload them as .txt files because github hates real code. But you're all smart cookies)

Edit: Both versions are running the same Microsoft Terminal version: 1.13.11431.0

Edit 2: This appears to be an issue with monospace font rendering. Using MesloLGS NF works perfectly, however using MesloLGM NF results in the cutoff italics. See

[scallaway]

I'm seeing something related when rendering text (code comments) with italics;

As I type across the line, the cursor seems to move further and further to the right, and become disjointed from where the text is actually getting displayed;

When in insert mode in Vim, you can see clearly where the cursor is pointing to (the vertical bar) vs. where the letter is actually going to be inserted (to the left of that black box).

This looks to be some sort of mathematical pixelling issue?

[DHowett]

You're right. This is sort of the opposite of the original report, but the root cause is the same. Text will be cut off on the right side when the italic or bold version is wider than the normal version, and it will spring back (for lack of a better term) and squeeze over to the left when it's narrower.

The root cause here is that our current text rendering engine tries to batch text into identical runs--that is, groups of characters with the same display attributes--and render them all at once. It helps us combine things like a base character and a combining diacritic (e + acute), but it also means that the font's native sizing and sometimes kerning take effect. When you do something that splits the display attributes (like, in your case you have cursorcolumn enabled), we end up doing this:

[One big render containing most of the text                 ] [e]

... and that one big render follows the font's native sizing.

At the end of the day, this isn't going to get better until we make the cell-by-cell rendering engine the default; the work to complete it is being tracked in #9999. I believe this case already works over there, but I haven't validated it with all fonts.

That's probably going to be the most complete solution to this issue, so I'm tempted to close this as a duplicate and recommend testing out the "new experimental text rendering engine" in the meantime.

What do you think? (Both the team and the community!)

[Nosamdaman]

What do you think? (Both the team and the community!)

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.

[jfaz1]

Hey all, tried using the new experimental text rendering engine and it still cuts off italics (using Dina Remaster). Just checking if it's supposed to be working already or not since @DHowett mentioned that this case already works over there, but I may be misunderstanding. If anything it's actually worse with it enabled (more than just the last italicized character is removed):

[DHowett]

Huh. @lhecker, should we measure cell extents in Atlas by checking all three fonts (bold, italic, regular) that the user could encounter? This will make the window wider IN MOST CASES for poorly-behaved fonts like the one @jfaz1 is using, but it would resolve this issue once and for all.