awful font rendering quality #14142

@skyline75489 commented on GitHub (Jun 7, 2021):

Can you try this https://github.com/microsoft/terminal/issues/10074#issuecomment-837708983 ?

@skyline75489 commented on GitHub (Jun 7, 2021): Can you try this https://github.com/microsoft/terminal/issues/10074#issuecomment-837708983 ?

claunia commented

@manxorist commented on GitHub (Jun 7, 2021):

Can you try this #10074 (comment) ?

According to documentation "grayscale" should be the default. Anyway, setting either "grayscale" or "cleartype" does not fix anything. "aliased" makes it even worse.

@manxorist commented on GitHub (Jun 7, 2021): > Can you try this [#10074 (comment)](https://github.com/microsoft/terminal/issues/10074#issuecomment-837708983) ? According to documentation `"grayscale"` should be the default. Anyway, setting either `"grayscale"` or `"cleartype"` does not fix anything. `"aliased"` makes it even worse.

claunia commented

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

I'm surprised the old console renders like that: requesting a size of 8 from the vintage console gets you eight pixels, whereas in WT you're getting eight points.

Assuming you're using a 100% scale display, it would be more equitable to compare 6pt in Windows Terminal against 8px in conhost. This will impact hinting, which can make a huge difference in the appearance of a font.

That's not to say that we don't render fonts differently than conhost, of course.

@DHowett commented on GitHub (Jun 7, 2021): I'm surprised the old console renders like that: requesting a size of 8 from the vintage console gets you _eight pixels_, whereas in WT you're getting eight _points_. Assuming you're using a 100% scale display, it would be more equitable to compare 6pt in Windows Terminal against 8px in conhost. This will impact hinting, which can make a huge difference in the appearance of a font. That's not to say that we don't render fonts differently than conhost, of course.

claunia commented

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

Ugh, that should teach me to read the report. Sorry, I totally missed that you did use pixels in conhost. Feel free to ignore me.

@DHowett commented on GitHub (Jun 7, 2021): Ugh, that should teach me to read the report. Sorry, I totally missed that you did use pixels in conhost. Feel free to ignore me.

claunia commented

@manxorist commented on GitHub (Jun 7, 2021):

Assuming you're using a 100% scale display

Yes, I am using a 100% scale display with as far as I know completely default font scaling and display scaling settings.

Ignoring the rest 😏

Graphics driver is NVidia, however I assume that does not matter, given that enforcing software rendering did not change anything.

FWIW, I am also using Liberation Mono 8pt as the font in Visual Studio. Also works properly there.

@manxorist commented on GitHub (Jun 7, 2021): > Assuming you're using a 100% scale display Yes, I am using a 100% scale display with as far as I know completely default font scaling and display scaling settings. Ignoring the rest :smirk: Graphics driver is NVidia, however I assume that does not matter, given that enforcing software rendering did not change anything. FWIW, I am also using Liberation Mono 8pt as the font in Visual Studio. Also works properly there.

claunia commented

@j4james commented on GitHub (Jun 8, 2021):

It almost looks to me like Windows Terminal is picking up a different font. For example, look at the lowercase c and s letters in the word "accusam". They look completely different on Windows Terminal compared to putty and conhost. Maybe that's just detail that was lost because the letters are smaller, but it's weird. The size ratio between uppercase and lowercase letters is different too.

I'm curious whether there are still obvious differences when comparing at larger sizes. Perhaps it's some kind of rounding issue in the DX renderer's size calculation when trying to align a small font size to an exact pixel boundary.

@j4james commented on GitHub (Jun 8, 2021): It almost looks to me like Windows Terminal is picking up a different font. For example, look at the lowercase c and s letters in the word "accusam". They look completely different on Windows Terminal compared to putty and conhost. Maybe that's just detail that was lost because the letters are smaller, but it's weird. The size ratio between uppercase and lowercase letters is different too. I'm curious whether there are still obvious differences when comparing at larger sizes. Perhaps it's some kind of rounding issue in the DX renderer's size calculation when trying to align a small font size to an exact pixel boundary.

claunia commented

@manxorist commented on GitHub (Jun 8, 2021):

I'm curious whether there are still obvious differences when comparing at larger sizes.

To me, it looks like the problem is less pronounced with larger font sizes.

If I had to guess what's going wrong, I would say it looks like in Windows Terminal, some kind of spacing between the lines gets added and the font size gets changed smaller a bit to compensate. As to why, I have no idea.

Neither additional line spacing alone nor in combination with adjusted smaller font size is acceptable font rendering in my opinion. I have been using Liberation Mono 8pt for about 10 years in various Windows programs (Console Window, Notepad, Notepad++, Visual Studio, PuTTY, ...) as well as in Linux (Mate Terminal, Mate Pluma). Apart from minor differences in anti-aliasing between Cleartype on Windows and Freetype on Linux, it looks identical everywhere except in Windows Terminal.

@manxorist commented on GitHub (Jun 8, 2021): > I'm curious whether there are still obvious differences when comparing at larger sizes. To me, it looks like the problem is less pronounced with larger font sizes. If I had to guess what's going wrong, I would say it looks like in Windows Terminal, some kind of spacing between the lines gets added and the font size gets changed smaller a bit to compensate. As to why, I have no idea. Neither additional line spacing alone nor in combination with adjusted smaller font size is acceptable font rendering in my opinion. I have been using Liberation Mono 8pt for about 10 years in various Windows programs (Console Window, Notepad, Notepad++, Visual Studio, PuTTY, ...) as well as in Linux (Mate Terminal, Mate Pluma). Apart from minor differences in anti-aliasing between Cleartype on Windows and Freetype on Linux, it looks identical everywhere except in Windows Terminal.

claunia commented

@zadjii-msft commented on GitHub (Jul 6, 2021):

I'm gonna /cc @miniksa. He's the font expert, he might have some idea.

@zadjii-msft commented on GitHub (Jul 6, 2021): I'm gonna /cc @miniksa. He's the font expert, he might have some idea.

claunia commented

@miniksa commented on GitHub (Jul 6, 2021):

Actually... I think @lhecker was working on a resolution for this already.

@miniksa commented on GitHub (Jul 6, 2021): Actually... I think @lhecker was working on a resolution for this already.

claunia commented

@lhecker commented on GitHub (Jul 6, 2021):

I'll put this on my backlog and test my theoretical fix on the above font. If it fixes it, I'll submit a PR right away.

@lhecker commented on GitHub (Jul 6, 2021): I'll put this on my backlog and test my theoretical fix on the above font. If it fixes it, I'll submit a PR right away.

claunia commented

@lhecker commented on GitHub (Jul 7, 2021):

My change makes some things a bit better and some things a bit worse:

I think the issue here is that we use natural scaling for fonts, whereas GDI (which is what "console" and "putty" use) tries to always fit fonts into the pixel grid. I believe DirectWrite can do the same, but it's not as trivial. We need to look into this more.

@lhecker commented on GitHub (Jul 7, 2021): My change makes some things a bit better and some things a bit worse: ![image](https://user-images.githubusercontent.com/2256941/124683236-e022be00-decc-11eb-9626-f674407d9597.png) I think the issue here is that we use natural scaling for fonts, whereas GDI (which is what "console" and "putty" use) tries to always fit fonts into the pixel grid. I believe DirectWrite can do the same, but it's not as trivial. We need to look into this more.

claunia commented

@manxorist commented on GitHub (Feb 4, 2022):

Reading about a new experimental text rendering engine in 1.13-preview (https://devblogs.microsoft.com/commandline/windows-terminal-preview-1-13-release/#new-rendering-engine), I retested this issue with the current preview version. In my opinion, the rendering quality is significantly improved up to the point I would consider it almost fixed. The only remaining problem is that the line spacing is bigger than old Console Window.

The screenshot shows Windows Terminal 1.11.3471.0 / Windows Terminal Preview 1.13.10336.0 (with experimental atlas engine) / Console Window (Windows 10 21H2 19044.1469) side by side.

@manxorist commented on GitHub (Feb 4, 2022): Reading about a new experimental text rendering engine in 1.13-preview (<https://devblogs.microsoft.com/commandline/windows-terminal-preview-1-13-release/#new-rendering-engine>), I retested this issue with the current preview version. In my opinion, the rendering quality is significantly improved up to the point I would consider it *almost fixed*. The only remaining problem is that the line spacing is bigger than old Console Window. The screenshot shows Windows Terminal 1.11.3471.0 / Windows Terminal Preview 1.13.10336.0 (with experimental atlas engine) / Console Window (Windows 10 21H2 19044.1469) side by side. ![terminal-1 11-terminal-1 13-preview-console](https://user-images.githubusercontent.com/6185338/152530108-150ef3de-073e-4bdf-b26e-a6450707b131.png)

claunia commented

@lhecker commented on GitHub (Feb 4, 2022):

@manxorist What happens if you enable ClearType? Does that further improve things?

This is what I get:

I'm glad that the font quality could improved this much!
Our line spacing algorithm is surprisingly difficult. You can find it here (cellHeight/Width are the resulting values per grid cell): 5238235268/src/renderer/atlas/AtlasEngine.api.cpp (L565-L579)

I used to use a different algorithm with reduced space for ascenders and descenders, but that lead to cut off glyphs for various asian scripts. Furthermore those asian scripts are often a bit taller in Windows Terminal, which improves their legibility. For instance if you try to paste georgian script in those programs you'll find that they're 10px tall in Windows Terminal 1.13 and only 9px tall in conhost.
But the algorithm is only the first version. If someone has an idea how to improve it I'll happily merge it as long as it doesn't cut off glyphs (because, to be honest, I'd also like to reduce the line height). Maybe it's already enough to remove the halfGap parameter. 🙂

@lhecker commented on GitHub (Feb 4, 2022): @manxorist What happens if you enable ClearType? Does that further improve things? This is what I get: ![image](https://user-images.githubusercontent.com/2256941/152539547-563680c8-1aab-4864-a02a-9fc8cc43403d.png) I'm glad that the font quality could improved this much! Our line spacing algorithm is surprisingly difficult. You can find it here (cellHeight/Width are the resulting values per grid cell): https://github.com/microsoft/terminal/blob/5238235268e32dc6ad1bf2c62b44a28eb16a272b/src/renderer/atlas/AtlasEngine.api.cpp#L565-L579 I used to use a different algorithm with reduced space for ascenders and descenders, but that lead to cut off glyphs for various asian scripts. Furthermore those asian scripts are often a bit taller in Windows Terminal, which improves their legibility. For instance if you try to paste georgian script in those programs you'll find that they're 10px tall in Windows Terminal 1.13 and only 9px tall in conhost. But the algorithm is only the first version. If someone has an idea how to improve it I'll happily merge it as long as it doesn't cut off glyphs (because, to be honest, I'd also like to reduce the line height). Maybe it's already enough to remove the `halfGap` parameter. 🙂

claunia commented

@manxorist commented on GitHub (Feb 4, 2022):

@manxorist What happens if you enable ClearType? Does that further improve things?

Cleartype only changes things very subtly.

1.11 | 1.13 altas greyscale | 1,13 atlas cleartype | conhost

I used to use a different algorithm with reduced space for ascenders and descenders, but that lead to cut off glyphs for various asian scripts. Furthermore those asian scripts are often a bit taller in Windows Terminal, which improves their legibility. For instance if you try to paste georgian script in those programs you'll find that they're 10px tall in Windows Terminal 1.13 and only 9px tall in conhost. But the algorithm is only the first version. If someone has an idea how to improve it I'll happily merge it as long as it doesn't cut off glyphs (because, to be honest, I'd also like to reduce the line height). Maybe it's already enough to remove the halfGap parameter. 🙂

I understand that it is important to also support all glyphs from non-western scripts properly, and thus rendering that takes these into account looks like a sensible default to me. However, traditional terminal usage probably mostly deals with only ASCII, at least for some users. Maybe an additional advanced setting could be added that lets the user choose between compatible and condensed line spacing?

@manxorist commented on GitHub (Feb 4, 2022): > @manxorist What happens if you enable ClearType? Does that further improve things? Cleartype only changes things very subtly. 1.11 | 1.13 altas greyscale | 1,13 atlas cleartype | conhost ![1 11-1 13atlas-greyscale-1 13atlas-cleartype-console](https://user-images.githubusercontent.com/6185338/152549106-360a6fca-1bca-4159-99a2-63328c3f1bba.png) > I used to use a different algorithm with reduced space for ascenders and descenders, but that lead to cut off glyphs for various asian scripts. Furthermore those asian scripts are often a bit taller in Windows Terminal, which improves their legibility. For instance if you try to paste georgian script in those programs you'll find that they're 10px tall in Windows Terminal 1.13 and only 9px tall in conhost. But the algorithm is only the first version. If someone has an idea how to improve it I'll happily merge it as long as it doesn't cut off glyphs (because, to be honest, I'd also like to reduce the line height). Maybe it's already enough to remove the `halfGap` parameter. 🙂 I understand that it is important to also support all glyphs from non-western scripts properly, and thus rendering that takes these into account looks like a sensible default to me. However, traditional terminal usage probably mostly deals with only ASCII, at least for some users. Maybe an additional advanced setting could be added that lets the user choose between compatible and condensed line spacing?

claunia commented

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

Maybe an additional advanced setting could be added that lets the user choose between compatible and condensed line spacing?

There's already an issue for customizing the line spacing - see #3498.

@j4james commented on GitHub (Feb 4, 2022): > Maybe an additional advanced setting could be added that lets the user choose between compatible and condensed line spacing? There's already an issue for customizing the line spacing - see #3498.

claunia commented

@lhecker commented on GitHub (Aug 16, 2022):

I think I'll take the liberty to close this issue. My personal understanding is that the font rendering we get in AtlasEngine is as good as it gets with Direct2D and DirectWrite (which we'd like to continue to use) and line spacing will be tackled as part of #3498.

@lhecker commented on GitHub (Aug 16, 2022): I think I'll take the liberty to close this issue. My personal understanding is that the font rendering we get in AtlasEngine is as good as it gets with Direct2D and DirectWrite (which we'd like to continue to use) and line spacing will be tackled as part of #3498.

claunia commented

@manxorist commented on GitHub (Aug 17, 2022):

@lhecker Well, if Windows Terminal cannot achieve the same rendering quality and line density as other terminals, this currently is and will continue to be a major issue for me. The fact that you "like to use" some particular rendering techniques does not invalidate the problem itself.

Please, either tag it as wontfix, or leave it open until Line Spacing can be configured properly.
I cannot consider this fixed or closed at all in the current state of things.

@manxorist commented on GitHub (Aug 17, 2022): @lhecker Well, if Windows Terminal cannot achieve the same rendering quality and line density as other terminals, this currently is and will continue to be a major issue for me. The fact that you "like to use" some particular rendering techniques does not invalidate the problem itself. Please, either tag it as wontfix, or leave it open until Line Spacing can be configured properly. I cannot consider this fixed or closed at all in the current state of things.

claunia commented

@zadjii-msft commented on GitHub (Aug 17, 2022):

leave it open until Line Spacing can be configured properly

We're already tracking that in #3498. Feel free to go give that thread a 👍

@zadjii-msft commented on GitHub (Aug 17, 2022): > leave it open until Line Spacing can be configured properly We're already tracking that in #3498. Feel free to go give that thread a 👍

claunia commented

@manxorist commented on GitHub (Aug 17, 2022):

Also, with Windows Terminal 1.14.1962.0, I cannot even get the improved rendering output that I did see with 1.13 preview any more:

Console 12px:

PuTTY 8pt:

Windows Terminal 1.14.1962.0 8pt:

Windows Terminal 1.14.1962.0 9pt:

So, nothing fixed. Now it is confused about what 8pt means (compared to every other program).

You could maybe at least try the provided test case before closing issues.

@manxorist commented on GitHub (Aug 17, 2022): Also, with Windows Terminal 1.14.1962.0, I cannot even get the improved rendering output that I did see with 1.13 preview any more: Console 12px: ![windows-console-12px](https://user-images.githubusercontent.com/6185338/185185870-35b7f17f-bd34-4002-a57b-02580aebf547.png) PuTTY 8pt: ![putty-8pt](https://user-images.githubusercontent.com/6185338/185185915-a838ae38-5e3e-46ef-8831-89c4099417ea.png) Windows Terminal 1.14.1962.0 8pt: ![windows-terminal-1 14 1962 0-8pt-greyscale](https://user-images.githubusercontent.com/6185338/185186021-6ff97d99-c64f-496e-a347-e64b0166ca01.png) Windows Terminal 1.14.1962.0 9pt: ![windows-terminal-1 14 1962 0-9pt-greyscale](https://user-images.githubusercontent.com/6185338/185186120-ad26a774-4d39-43f9-83fb-9223bf16a0bc.png) So, nothing fixed. Now it is confused about what `8pt` means (compared to every other program). You could maybe at least try the provided test case before closing issues.

claunia commented

@lhecker commented on GitHub (Aug 17, 2022):

@manxorist Correct me if I'm wrong, but I believe Windows Terminal 1.14.1962.0 is a non-Preview version. It doesn't have the new text renderer, so it can't have the improved font rendering. Can you please try a Preview version (currently 1.15)?
The new text renderer is feature gated and has stayed in Preview ever since. 1.16 will be the first non-Preview version which gets the new text renderer.

@lhecker commented on GitHub (Aug 17, 2022): @manxorist Correct me if I'm wrong, but I believe Windows Terminal 1.14.1962.0 is a non-Preview version. It doesn't have the new text renderer, so it can't have the improved font rendering. Can you please try a Preview version (currently 1.15)? The new text renderer is feature gated and has stayed in Preview ever since. 1.16 will be the first non-Preview version which gets the new text renderer.

claunia commented

@manxorist commented on GitHub (Aug 17, 2022):

@lhecker Thanks, I might be confused by the versioning and preview/release management that Windows Terminal uses.

Seriously, what's the point of versioning preview versions in a way that does not relate at all to release versions?

If the new renderer is still experimental and deemed unfit for a release version, then even more so this issue should not get closed, as it is (from my perspective) totally uncertain whether it will ever hit a release version at all.

1.15.2002.0 Preview Atlas 8pt:

That's 1.13 Preview Atlas level performance.

@manxorist commented on GitHub (Aug 17, 2022): @lhecker Thanks, I might be confused by the versioning and preview/release management that Windows Terminal uses. Seriously, what's the point of versioning preview versions in a way that does not relate at all to release versions? If the new renderer is still experimental and deemed unfit for a release version, then even more so this issue should not get closed, as it is (from my perspective) totally uncertain whether it will ever hit a release version at all. 1.15.2002.0 Preview Atlas 8pt: ![windows-terminal-1 15 2002 0-8pt-greyscale](https://user-images.githubusercontent.com/6185338/185190042-9c2ace28-e253-43f3-872c-3d3f3bb5539e.png) That's 1.13 Preview Atlas level performance.

claunia commented

@lhecker commented on GitHub (Aug 17, 2022):

Here's a comparison between existing conhost/cmd.exe on the left and the latest AtlasEngine with all changes on main on the right; 100% display scale, Liberation Mono, 12px/8pt:

From what I can tell, the result from the new renderer is pretty good and wouldn't qualify as "awful" anymore like it did before. The line spacing thing is being tackled in another issue.

If the new renderer is still experimental and deemed unfit for a release version, then even more so this issue should not get closed, as it is (from my perspective) totally uncertain whether it will ever hit a release version at all.

The PR making it available in non-Preview has already merged. 🙂 It stayed in Preview a bit longer than other features, because it's a fairly large feature. BTW I heard someone might be working on the line spacing / glyph advance thing already... *wink*

@lhecker commented on GitHub (Aug 17, 2022): Here's a comparison between existing conhost/cmd.exe on the left and the latest AtlasEngine with all changes on main on the right; 100% display scale, Liberation Mono, 12px/8pt: ![image](https://user-images.githubusercontent.com/2256941/185191165-ea0bbd4d-adc7-498e-a7de-a8b2ddecff85.png) From what I can tell, the result from the new renderer is pretty good and wouldn't qualify as "awful" anymore like it did before. The line spacing thing is being tackled in another issue. > If the new renderer is still experimental and deemed unfit for a release version, then even more so this issue should not get closed, as it is (from my perspective) totally uncertain whether it will ever hit a release version at all. The PR making it available in non-Preview has already merged. 🙂 It stayed in Preview a bit longer than other features, because it's a fairly large feature. BTW I heard someone might be working on the line spacing / glyph advance thing already... \*wink\*

claunia commented

@manxorist commented on GitHub (Aug 17, 2022):

The PR making it available in non-Preview has already merged. 🙂

OK, I guess closing is fine then.

@manxorist commented on GitHub (Aug 17, 2022): > The PR making it available in non-Preview has already merged. 🙂 OK, I guess closing is fine then.

claunia commented