Italics &amp; Bold not rendering properly if they are the final character - text looks &#34;cut off&#34; #12871

@Nosamdaman commented on GitHub (Mar 4, 2021):

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

@Nosamdaman commented on GitHub (Mar 4, 2021): Interestingly, switching the font back and forth actually fixes the issue for anything that has already been printed.

claunia commented

@zadjii-msft commented on GitHub (Mar 4, 2021):

Huh. Good catch!

@zadjii-msft commented on GitHub (Mar 4, 2021): _Huh._ Good catch!

claunia commented

@vefatica commented on GitHub (Mar 4, 2021):

What is "set_color"?

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

@vefatica commented on GitHub (Mar 4, 2021): What is "set_color"? I have no problem doing it manually (in TCSH). ![image](https://user-images.githubusercontent.com/61856645/110033095-f0e8da80-7d06-11eb-9cef-0a2abba2fb1d.png)

claunia commented

@Nosamdaman commented on GitHub (Mar 4, 2021):

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.

@Nosamdaman commented on GitHub (Mar 4, 2021): 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. ![image](https://user-images.githubusercontent.com/54364725/110033490-75d3f400-7d07-11eb-9683-ac0e0df025f9.png)

claunia commented

@237dmitry commented on GitHub (Mar 4, 2021):

Everything seems to be fine:

@237dmitry commented on GitHub (Mar 4, 2021): Everything seems to be fine: ![aaa](https://user-images.githubusercontent.com/78153320/110034670-ca00c780-7d4b-11eb-9b16-d81cc64cd77d.png)

claunia commented

@Nosamdaman commented on GitHub (Mar 4, 2021):

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.

@Nosamdaman commented on GitHub (Mar 4, 2021): 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.

claunia commented

@vefatica commented on GitHub (Mar 4, 2021):

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

@vefatica commented on GitHub (Mar 4, 2021): 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). ![image](https://user-images.githubusercontent.com/61856645/110035581-db28e480-7d09-11eb-91ba-5187c2fa5c03.png)

claunia commented

@j4james commented on GitHub (Mar 4, 2021):

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.

@j4james commented on GitHub (Mar 4, 2021): 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.

claunia commented

@Nosamdaman commented on GitHub (Mar 4, 2021):

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

@Nosamdaman commented on GitHub (Mar 4, 2021): That makes sense, except I'm not changing the background color as far as I know

claunia commented

@j4james commented on GitHub (Mar 4, 2021):

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.

@j4james commented on GitHub (Mar 4, 2021): 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.

claunia commented

@Nosamdaman commented on GitHub (Mar 4, 2021):

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.

@Nosamdaman commented on GitHub (Mar 4, 2021): 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.

claunia commented

@237dmitry commented on GitHub (Mar 4, 2021):

this only happens when you're changing colors

May be this is "fish"-behavior

@237dmitry commented on GitHub (Mar 4, 2021): > this only happens when you're changing colors ![bbb](https://user-images.githubusercontent.com/78153320/110037228-2b766580-7d4f-11eb-8b5b-a00771b3b19b.png) May be this is "fish"-behavior

claunia commented

2026-01-31 03:27:29 +00:00

@Nosamdaman commented on GitHub (Mar 4, 2021):

I've confirmed it happens in bash as well

@Nosamdaman commented on GitHub (Mar 4, 2021): I've confirmed it happens in bash as well

claunia commented

@j4james commented on GitHub (Mar 4, 2021):

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.

@j4james commented on GitHub (Mar 4, 2021): > 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.

claunia commented

2026-01-31 03:27:29 +00:00

@DHowett commented on GitHub (Mar 4, 2021):

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 commented on GitHub (Mar 4, 2021): 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

claunia commented

2026-01-31 03:27:29 +00:00

@Antonio-Bennett commented on GitHub (Apr 3, 2021):

@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

@Antonio-Bennett commented on GitHub (Apr 3, 2021): @DHowett So for me in the shell (fish) and on Ubuntu 20.10 it is fine ![image](https://user-images.githubusercontent.com/31296212/113462558-82736700-93ef-11eb-83a0-0526678a7d95.png) But in Neovim comments that are italic has this issue for some reason ![image](https://user-images.githubusercontent.com/31296212/113462646-e6962b00-93ef-11eb-963c-9078ea36cfcf.png)

claunia commented

@xbb commented on GitHub (Apr 19, 2021):

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

@xbb commented on GitHub (Apr 19, 2021): I'm having the same issue, which I notice only with neovim so far and fonts without italic variant

claunia commented

@Gee19 commented on GitHub (May 24, 2021):

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

@Gee19 commented on GitHub (May 24, 2021): 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. ![grayscale_vim](https://user-images.githubusercontent.com/5077424/119307765-30ee9800-bc3a-11eb-9fed-9f7e0429cf8b.PNG) Although, `grayscale` seemingly fixes it in the shell, zsh in this case. `echo -e "\e[3m foo {{{ \e[23m"` ![grayscale_shell](https://user-images.githubusercontent.com/5077424/119307756-2d5b1100-bc3a-11eb-9ae6-511d50104ded.PNG) ``` Windows Terminal Preview Version: 1.8.1032.0 ```

claunia commented

@chrisdcao commented on GitHub (Jun 24, 2021):

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 commented on GitHub (Jun 24, 2021): 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?... ![Screenshot_34](https://user-images.githubusercontent.com/68319923/123201426-da94a380-d4dc-11eb-93c6-afa6b8db212e.png) ### 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)

claunia commented

@chrisdcao commented on GitHub (Jun 24, 2021):

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:

@chrisdcao commented on GitHub (Jun 24, 2021): 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: ![Screenshot_35](https://user-images.githubusercontent.com/68319923/123202027-0ebc9400-d4de-11eb-9189-b46c507fdfe3.png)

claunia commented

@DHowett commented on GitHub (Jun 24, 2021):

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.

@DHowett commented on GitHub (Jun 24, 2021): _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.

claunia commented

@chrisdcao commented on GitHub (Jun 24, 2021):

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

@chrisdcao commented on GitHub (Jun 24, 2021): 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

claunia commented

@aprowe commented on GitHub (Sep 13, 2021):

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

@aprowe commented on GitHub (Sep 13, 2021): Any updates on this? Literally the ONLY issue I have with windows terminal is this!

claunia commented

@zadjii-msft commented on GitHub (Sep 14, 2021):

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

@zadjii-msft commented on GitHub (Sep 14, 2021): Nope. We'll make sure to update this thread when there is. In the meantime, might I recommend the Subscribe button? ![image](https://user-images.githubusercontent.com/18356694/91237459-5cbb0c80-e700-11ea-9347-b9b1ec2813b1.png) That way you'll be notified of any updates to this thread, without needlessly pinging everyone on this thread ☺️

claunia commented

@Rz-Rz commented on GitHub (Dec 4, 2021):

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

@Rz-Rz commented on GitHub (Dec 4, 2021): I have the same problem when using Neovim with WSL2 and Windows Terminal

claunia commented

@Pranav-Badrinathan commented on GitHub (Jan 4, 2022):

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 commented on GitHub (Jan 4, 2022): For me, using Inconsolata (Nerd Font version), I get black boxes, presumably where the next character is supposed to be..? ![image](https://user-images.githubusercontent.com/40524763/147993994-b46f46e3-9b02-4a88-b3ec-63c0010e6ccb.png) Cascadia Code does tend to do what is mentioned above and clips text.

claunia commented

@DHowett commented on GitHub (Jan 4, 2022):

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

@DHowett commented on GitHub (Jan 4, 2022): @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.

claunia commented

@j4james commented on GitHub (Jan 4, 2022):

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

@j4james commented on GitHub (Jan 4, 2022): Yeah, this is really more a variant of #10678, only kind of in reverse. I'm assuming the atlas renderer should fix this.

claunia commented

@Pranav-Badrinathan commented on GitHub (Jan 5, 2022):

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

@Pranav-Badrinathan commented on GitHub (Jan 5, 2022): > ...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!

claunia commented

@bryant-the-coder commented on GitHub (Feb 1, 2022):

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

@bryant-the-coder commented on GitHub (Feb 1, 2022): has anyone has a solution for this? it is because bold font is showing as a regular font and not being bolded

claunia commented

@wespiard commented on GitHub (Feb 25, 2022):

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

@wespiard commented on GitHub (Feb 25, 2022): This is still a pain for me. It's the only reason I'm not using Terminal as my daily driver.

claunia commented

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

@djdv commented on GitHub (Apr 21, 2022):

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 (87f5034db1) 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"

@djdv commented on GitHub (Apr 21, 2022): 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: ![Untitled](https://user-images.githubusercontent.com/13862850/164489034-b55282ca-3da7-4fd0-a133-d0ed9058bd2c.png) 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" ```

claunia commented

2026-01-31 03:27:33 +00:00

@j4james commented on GitHub (Apr 21, 2022):

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

@j4james commented on GitHub (Apr 21, 2022): > > 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](https://github.com/microsoft/terminal/commit/87f5034db1eb0102358d05eeff82ebcc8032c9be)) 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).

claunia commented

2026-01-31 03:27:33 +00:00

@Acceyuriko commented on GitHub (May 19, 2022):

I have the same issue when I use neovim.

Environment:

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

@Acceyuriko commented on GitHub (May 19, 2022): I have the same issue when I use neovim. ![image](https://user-images.githubusercontent.com/7571003/169221339-90cceb09-f580-414d-b2fe-b371046604bd.png) Environment: ``` Windows Terminal Version: 1.12.10983.0 Font: CaskaydiaCove NF Antialiasing: ClearType ```

claunia commented

2026-01-31 03:27:33 +00:00

@mrbeardad commented on GitHub (May 20, 2022):

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

@mrbeardad commented on GitHub (May 20, 2022): How about to use the italic style font in the font family instead of changing the inclination of font? ![image](https://user-images.githubusercontent.com/54128430/169547186-ccea813d-ff21-45f0-98a7-40b1d1ffae28.png)

claunia commented

@DHowett commented on GitHub (May 20, 2022):

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

@DHowett commented on GitHub (May 20, 2022): > 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. :)

claunia commented

@jiashun0011 commented on GitHub (May 20, 2022):

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.

@jiashun0011 commented on GitHub (May 20, 2022): > I have the same issue when I use neovim. ![image](https://user-images.githubusercontent.com/7571003/169221339-90cceb09-f580-414d-b2fe-b371046604bd.png) > > Environment: > > ``` > Windows Terminal Version: 1.12.10983.0 > Font: CaskaydiaCove NF > Antialiasing: ClearType > ``` I have the same issue too.

claunia commented

@mrbeardad commented on GitHub (May 21, 2022):

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.

@mrbeardad commented on GitHub (May 21, 2022): > > 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? ![image](https://user-images.githubusercontent.com/54128430/169644201-077d9290-ee6e-4f5f-817d-39a34df1e47c.png) I'm 100% sure my bold font information is correct, because vscode could render it correctly. ![image](https://user-images.githubusercontent.com/54128430/169644163-c73f1e23-50e7-4837-bc11-492409c88556.png)

claunia commented

@DHowett commented on GitHub (May 23, 2022):

Yes, you'll want to set this setting:

@DHowett commented on GitHub (May 23, 2022): Yes, you'll want to set this setting: <img width="439" alt="image" src="https://user-images.githubusercontent.com/189190/169875481-03dd46e2-faab-4854-aaed-df26db28a175.png">

claunia commented

@mrbeardad commented on GitHub (May 24, 2022):

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

@mrbeardad commented on GitHub (May 24, 2022): I'm sorry that it does not work for me. #13150

claunia commented

@reaz1995 commented on GitHub (May 29, 2022):

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

@reaz1995 commented on GitHub (May 29, 2022): 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

claunia commented

@wespiard commented on GitHub (Jun 3, 2022):

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.

@wespiard commented on GitHub (Jun 3, 2022): > Yes, you'll want to set this setting: > > <img alt="image" width="439" src="https://user-images.githubusercontent.com/189190/169875481-03dd46e2-faab-4854-aaed-df26db28a175.png"> 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. ![image](https://user-images.githubusercontent.com/1278350/171759507-a67b342a-dd0a-495d-b647-a67e9139bc25.png)

claunia commented

@jiashun0011 commented on GitHub (Jun 9, 2022):

Mark and the annoying issue is still there...

@jiashun0011 commented on GitHub (Jun 9, 2022): Mark and the annoying issue is still there...

claunia commented

@yueyingjuesha commented on GitHub (Jul 2, 2022):

Overall workflow blocked still waiting for these issues to be fixed

@yueyingjuesha commented on GitHub (Jul 2, 2022): Overall workflow blocked still waiting for these issues to be fixed

claunia commented

@miversen33 commented on GitHub (Jul 25, 2022):

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

@miversen33 commented on GitHub (Jul 25, 2022): 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](https://github.com/microsoft/terminal/files/9181732/not-broken-italics-settings.txt) [broken-italics-settings.txt](https://github.com/microsoft/terminal/files/9181733/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](https://github.com/ryanoasis/nerd-fonts/tree/master/patched-fonts/Meslo/S/Regular/complete) works perfectly, however using [MesloLGM NF](https://github.com/ryanoasis/nerd-fonts/tree/master/patched-fonts/Meslo/M/Regular/complete) results in the cutoff italics. See ![image](https://user-images.githubusercontent.com/2640668/180796161-02eb567c-c867-4ab7-9ae7-6080cb9063a7.png)

claunia commented

@scallaway commented on GitHub (Jul 28, 2022):

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?

@scallaway commented on GitHub (Jul 28, 2022): I'm seeing something related when rendering text (code comments) with italics; ![image](https://user-images.githubusercontent.com/16577635/181595458-cd0af38e-6d44-4c3f-868e-7863d1bb8f23.png) 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; ![image](https://user-images.githubusercontent.com/16577635/181595601-2f3a934d-d55e-4bec-9aea-d87412178b15.png) ![image](https://user-images.githubusercontent.com/16577635/181595661-42abc951-24a3-4f28-bb16-6c8703fbe120.png) > 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?

claunia commented

@DHowett commented on GitHub (Jul 28, 2022):

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

@DHowett commented on GitHub (Jul 28, 2022): 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!)

claunia commented

@Nosamdaman commented on GitHub (Jul 30, 2022):

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.

@Nosamdaman commented on GitHub (Jul 30, 2022): > 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.

claunia commented

@jfaz1 commented on GitHub (Sep 6, 2022):

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

@jfaz1 commented on GitHub (Sep 6, 2022): 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): ![image](https://user-images.githubusercontent.com/56184947/188539306-e4b460c3-a7ec-4297-b2cb-abd43ec59755.png)

claunia commented

@DHowett commented on GitHub (Sep 6, 2022):

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.

@DHowett commented on GitHub (Sep 6, 2022): _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.

claunia commented

@lhecker commented on GitHub (Sep 6, 2022):

In 1.16 those glyphs won't be cut off anymore. But to retain a proper monospace grid we should implement your suggestion @DHowett.

@lhecker commented on GitHub (Sep 6, 2022): In 1.16 those glyphs won't be cut off anymore. But to retain a proper monospace grid we should implement your suggestion @DHowett.

claunia commented

@j4james commented on GitHub (Sep 6, 2022):

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

@j4james commented on GitHub (Sep 6, 2022): @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. ![image](https://user-images.githubusercontent.com/4181424/188704215-ae0ad9ed-c7c7-4437-99d9-240c77182448.png)

claunia commented

@scallaway commented on GitHub (Sep 6, 2022):

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

This would be the way I'd expect this to be implemented?

I'm not sure, however, whether this uncovers other issues surrounding obscure placement of characters, especially with other glyphs.

I haven't had a chance to test the latest myself yet, but will try to give it a go for my use case in the next day.

@scallaway commented on GitHub (Sep 6, 2022): > @lhecker > 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). This would be the way I'd expect this to be implemented? I'm not sure, however, whether this uncovers other issues surrounding obscure placement of characters, especially with other glyphs. I haven't had a chance to test the latest myself yet, but will try to give it a go for my use case in the next day.

claunia commented

@lhecker commented on GitHub (Sep 6, 2022):

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

Yeah I still do, but it's not trivial to decide on a proper heuristic here. What I was planning to solve in the near term is joining ambiguous emojis with a trailing whitespace to make Windows Terminal behave like other terminals in that regard. Implementing the heuristic for that is pretty simple after all.

Implementing a glyph atlas with arbitrarily sized glyphs correctly and properly is a lot more annoying. This will require the use of a bin packing algorithm to store glyph textures. Then during rendering you have to render each glyph on its own rectangular polygon (quad). This is how most text renderers including Direct2D do it. It's easy to do this sloppy and hard to do correctly.

After all, you can't just draw each glyph on its own quad. What if the overlapping glyphs intentionally form a ligature? Overlapping them by simply alpha-blending them would mean that the anti-aliased border of the glyph ends up too opaque at the point of the overlap. It also doesn't work with ClearType which a lot of our users use (ClearType doesn't support alpha blending). Joining overlapping glyphs and rasterizing them as one large glyph solves the problem.

But what is the heuristic here? If you simply join all overlapping glyphs you might get a perfect result, but now a screen full of slanted/italic text would all be rendered as one huge glyph with effectively no caching at all. The performance would end up being terrible. Given that Direct2D already handles this perfectly, it might be easier to port our text rendering improvements to Direct2D than it is to replicate Direct2Ds text renderer in Windows Terminal in full.

I'm not a text rendering expert and I've always considered our custom text renderer ("AtlasEngine") to be a "hack" which just works around our immediate performance problems we had. It's a nice bonus that it performs much much faster than Direct2D ever could, thanks to us assuming that each glyph fits into the terminal's raster grid, but clearly this isn't a perfect solution either.

If anyone is knowledgeable about text rendering and has ideas how to improve ours I'd be happy to hear about it.

I haven't had a chance to test the latest myself yet, but will try to give it a go for my use case in the next day.

1.16 hasn't been released yet, but will be most likely this week.

@lhecker commented on GitHub (Sep 6, 2022): > 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). Yeah I still do, but it's not trivial to decide on a proper heuristic here. What I was planning to solve in the near term is joining ambiguous emojis with a trailing whitespace to make Windows Terminal behave like other terminals in that regard. Implementing the heuristic for that is pretty simple after all. Implementing a glyph atlas with arbitrarily sized glyphs correctly and properly is a lot more annoying. This will require the use of a bin packing algorithm to store glyph textures. Then during rendering you have to render each glyph on its own rectangular polygon (quad). This is how most text renderers including Direct2D do it. It's easy to do this sloppy and hard to do correctly. After all, you can't just draw each glyph on its own quad. What if the overlapping glyphs intentionally form a ligature? Overlapping them by simply alpha-blending them would mean that the anti-aliased border of the glyph ends up too opaque at the point of the overlap. It also doesn't work with ClearType which a lot of our users use (ClearType doesn't support alpha blending). Joining overlapping glyphs and rasterizing them as one large glyph solves the problem. But what is the heuristic here? If you simply join all overlapping glyphs you might get a perfect result, but now a screen full of slanted/italic text would all be rendered as one huge glyph with effectively no caching at all. The performance would end up being terrible. Given that Direct2D already handles this perfectly, it might be easier to port our text rendering improvements to Direct2D than it is to replicate Direct2Ds text renderer in Windows Terminal in full. I'm not a text rendering expert and I've always considered our custom text renderer ("AtlasEngine") to be a "hack" which just works around our immediate performance problems we had. It's a nice bonus that it performs much much faster than Direct2D _ever_ could, thanks to us assuming that each glyph fits into the terminal's raster grid, but clearly this isn't a perfect solution either. If anyone is knowledgeable about text rendering and has ideas how to improve ours I'd be happy to hear about it. > I haven't had a chance to test the latest myself yet, but will try to give it a go for my use case in the next day. 1.16 hasn't been released yet, but will be most likely this week.

claunia commented

@j4james commented on GitHub (Sep 6, 2022):

But what is the heuristic here? If you simply join all overlapping glyphs you might get a perfect result, but now a screen full of slanted/italic text would all be rendered as one huge glyph

But you surely don't need to join overlapping glyphs just because they're slanted? I would have thought the only time you really care about joining is if you've got an actual ligature, which I assumed you'd know from the font metrics somehow. Or am I wrong about that?

I accept you might still have a situation where you've got something like an italic W overlapping a non-italic H, with artifacts where the characters intersect, but it seems like that should be fairly rare, and even when it happens I suspect it would be less jarring than having excessive letter spacing everywhere.

I'm not super concerned about any of this stuff though. Just wanted to offer my thoughts on the subject. But I know very little about text rendering, so if I'm not making any sense, feel free to disregard.

@j4james commented on GitHub (Sep 6, 2022): > But what is the heuristic here? If you simply join all overlapping glyphs you might get a perfect result, but now a screen full of slanted/italic text would all be rendered as one huge glyph But you surely don't need to join overlapping glyphs just because they're slanted? I would have thought the only time you really care about joining is if you've got an actual ligature, which I assumed you'd know from the font metrics somehow. Or am I wrong about that? I accept you might still have a situation where you've got something like an italic `W` overlapping a non-italic `H`, with artifacts where the characters intersect, but it seems like that should be fairly rare, and even when it happens I suspect it would be less jarring than having excessive letter spacing everywhere. I'm not super concerned about any of this stuff though. Just wanted to offer my thoughts on the subject. But I know very little about text rendering, so if I'm not making any sense, feel free to disregard.

claunia commented

@lhecker commented on GitHub (Sep 6, 2022):

But you surely don't need to join overlapping glyphs just because they're slanted? I would have thought the only time you really care about joining is if you've got an actual ligature, which I assumed you'd know from the font metrics somehow. Or am I wrong about that?

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

@lhecker commented on GitHub (Sep 6, 2022): > But you surely don't need to join overlapping glyphs just because they're slanted? I would have thought the only time you really care about joining is if you've got an actual ligature, which I assumed you'd know from the font metrics somehow. Or am I wrong about that? 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. 🥲

claunia commented