starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-07-08 18:16:28 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

Font sizes in WT and conhost #18623

New Issue
Open
opened 2026-01-31 06:19:34 +00:00 by claunia · 6 comments
claunia commented 2026-01-31 06:19:34 +00:00
Owner
Copy Link

Originally created by @alabuzhev on GitHub (Oct 8, 2022).

Originally assigned to: @lhecker on GitHub.

Windows Terminal version

1.16.2641.0

Windows build number

10.0.19044.1889

Other Software

No response

Steps to reproduce

Apologies if this has already been discussed somewhere.

I prefer Consolas 20px. This is how it looks like in conhost:

conhost_consolas_20px
The cmd file used: sample.cmd.txt

I would like to get the same experience in WT, so I go to settings, select Consolas, 20, and...

wt_consolas_20pt
Oh. Ok, it says "Size of the font in points", I should've paid attention.
Ok, let's google what points are and how they relate to pixels:

https://blog.gimm.io/difference-between-pixel-px-and-point-pt-font-sizes-in-email-signatures/

A point (pt) is equal to 0.352778 millimeters, 0.0138889 inches, or 1.333 pixels.

https://graphicdesign.stackexchange.com/questions/199/point-vs-pixel-what-is-the-difference

A px is therefore 0.75 pt

Ok, if one px is 0.75 pt, then 20 px is 15 pt, right?

wt_consolas_15pt
No.

Well, apparently these are some other points then, but I'm getting tired and don't want to research it further. Let's try the scientific method.

10pt... No.
11pt... No.
12pt...

wt_consolas_12pt

Close. Width is nearly perfect, but height is too small.

13pt...

wt_consolas_13pt

Now height is nearly perfect, but width is too big. What the...
Ok, the new WT supports fractional font sizes, so let's try that:
...
12.64pt...

wt_consolas_12 64pt
Width is nearly perfect, height is nearly perfect, but... it's ugly. Too bold. With gaps.

No luck it seems. Let's try other apps just to check if it's possible.

Windows Notepad, 13pt:

notepad_consolas_13pt
A pixel-perfect match!

comparison_notepad_conhost

ConEmu, 20px:

conemu_consolas_20px
Also a pixel-perfect match:

comparison_conemu_notepad_conhost

So it is doable.

Expected Behavior

I want to see exactly the same picture in WT I used to see in conhost for over a decade.
With all its flexibility, advanced renderers etc. I expect it to be trivially achievable, if not out of the box.

Actual Behavior

No matter what I do, I cannot get the same results: the font is either too short or too wide, fractional sizes approximate it better, but the result is ugly. Meanwhile, in some other apps it just works.

P.S. I understand that fonts is a complex topic, vector curves not necessarily can perfectly fit into a pixel grid, there are different approximation methods etc., but I think there should be a way to get a familiar look & feel nevertheless.

Originally created by @alabuzhev on GitHub (Oct 8, 2022). Originally assigned to: @lhecker on GitHub. ### Windows Terminal version 1.16.2641.0 ### Windows build number 10.0.19044.1889 ### Other Software _No response_ ### Steps to reproduce Apologies if this has already been discussed somewhere. I prefer Consolas 20px. This is how it looks like in conhost: ![conhost_consolas_20px](https://user-images.githubusercontent.com/11453922/194710814-6a9b49ce-e87f-4b07-9e0d-fa02c65e6bba.png) The cmd file used: [sample.cmd.txt](https://github.com/microsoft/terminal/files/9739383/sample.cmd.txt) I would like to get the same experience in WT, so I go to settings, select Consolas, 20, and... ![wt_consolas_20pt](https://user-images.githubusercontent.com/11453922/194711021-2927cb72-3cf5-4df7-8603-be2df18a87cf.png) Oh. Ok, it says "Size of the font in **points**", I should've paid attention. Ok, let's google what points are and how they relate to pixels: https://blog.gimm.io/difference-between-pixel-px-and-point-pt-font-sizes-in-email-signatures/ > A point (pt) is equal to 0.352778 millimeters, 0.0138889 inches, or 1.333 pixels. https://graphicdesign.stackexchange.com/questions/199/point-vs-pixel-what-is-the-difference > A px is therefore 0.75 pt Ok, if one px is 0.75 pt, then 20 px is 15 pt, right? ![wt_consolas_15pt](https://user-images.githubusercontent.com/11453922/194711413-050faf38-00ad-434c-8fcb-e3ea7ffc3a0d.png) No. Well, apparently these are some other points then, but I'm getting tired and don't want to research it further. Let's try the scientific method. 10pt... No. 11pt... No. 12pt... ![wt_consolas_12pt](https://user-images.githubusercontent.com/11453922/194711527-4bea5851-c574-4bc2-99f0-8367bb4f4f22.png) Close. Width is nearly perfect, but height is too small. 13pt... ![wt_consolas_13pt](https://user-images.githubusercontent.com/11453922/194711699-d9c45925-a8ca-45ad-8f64-22609ab5fb3d.png) Now height is nearly perfect, but width is too big. What the... Ok, the new WT [supports fractional font sizes](https://github.com/microsoft/terminal/releases/tag/v1.16.2641.0), so let's try that: ... 12.64pt... ![wt_consolas_12 64pt](https://user-images.githubusercontent.com/11453922/194711803-7e12191e-48af-4e93-aead-c7f13d6d8246.png) Width is nearly perfect, height is nearly perfect, but... it's ugly. Too bold. With gaps. No luck it seems. Let's try other apps just to check if it's possible. Windows Notepad, 13pt: ![notepad_consolas_13pt](https://user-images.githubusercontent.com/11453922/194711938-67942d1e-9685-42f5-bda4-f875ffc38ba5.png) A pixel-perfect match! ![comparison_notepad_conhost](https://user-images.githubusercontent.com/11453922/194712246-d2ef7d07-6827-4bde-8933-014fc600750f.png) [ConEmu](https://github.com/Maximus5/ConEmu), 20px: ![conemu_consolas_20px](https://user-images.githubusercontent.com/11453922/194712266-bafe52fd-236b-4bdb-a9cc-198626821394.png) Also a pixel-perfect match: ![comparison_conemu_notepad_conhost](https://user-images.githubusercontent.com/11453922/194712360-f2fa5363-06f8-4649-92b4-7f7ceead02ae.png) So it is doable. ### Expected Behavior I want to see exactly the same picture in WT I used to see in conhost for over a decade. With all its flexibility, advanced renderers etc. I expect it to be trivially achievable, if not out of the box. ### Actual Behavior No matter what I do, I cannot get the same results: the font is either too short or too wide, fractional sizes approximate it better, but the result is ugly. Meanwhile, in some other apps it just works. --- P.S. I understand that fonts is a complex topic, vector curves not necessarily can perfectly fit into a pixel grid, there are different approximation methods etc., but I think there should be a way to get a familiar look & feel nevertheless.
claunia added the Issue-FeatureArea-RenderingProduct-TerminalArea-Fonts labels 2026-01-31 06:19:34 +00:00
claunia commented 2026-01-31 06:19:35 +00:00
Author
Owner
Copy Link

@alabuzhev commented on GitHub (Oct 11, 2022):

And another related issue: as I mentioned above, lines appear thicker and somewhat blurrier in WT (Atlas) with certain font sizes.
It is visible to some extent on double lines on the screenshots.
It could be related to font hinting differences.

Replacing defaultParams->GetRenderingMode() with DWRITE_RENDERING_MODE_GDI_CLASSIC here:
cacf66860f/src/renderer/atlas/dwrite.cpp (L37)
improves it significantly (notice also the absence of vertical artefacts within the █▄▌ and ▐▀ blocks in the 2nd case):

rendering_mode_wt

Test characters: ░▒▓│┤╡╢╖╕╣║╗╝╜╛┐└┴┬├─┼╞╟╚╔╩╦╠═╬╧╨╤╥╙╘╒╓╫╪┘┌█▄▌▐▀

@alabuzhev commented on GitHub (Oct 11, 2022): And another related issue: as I mentioned above, lines appear thicker and somewhat blurrier in WT (Atlas) with certain font sizes. It is visible to some extent on double lines on the screenshots. It could be related to [font hinting differences](https://stackoverflow.com/questions/7498553/direct2d-interface-and-blurry-text-issue). Replacing `defaultParams->GetRenderingMode()` with `DWRITE_RENDERING_MODE_GDI_CLASSIC` here: https://github.com/microsoft/terminal/blob/cacf66860f6c175672b3d030dcd166e372b2a8cc/src/renderer/atlas/dwrite.cpp#L37 improves it significantly (notice also the absence of vertical artefacts within the `█▄▌` and `▐▀` blocks in the 2nd case): ![rendering_mode_wt](https://user-images.githubusercontent.com/11453922/195201952-9b94d31d-f597-4a31-8568-33bdd83b3003.png) Test characters: `░▒▓│┤╡╢╖╕╣║╗╝╜╛┐└┴┬├─┼╞╟╚╔╩╦╠═╬╧╨╤╥╙╘╒╓╫╪┘┌█▄▌▐▀`
claunia commented 2026-01-31 06:19:35 +00:00
Author
Owner
Copy Link

@lhecker commented on GitHub (Oct 12, 2022):

Apologies if this has already been discussed somewhere.

I don't think we have! I'm actually really happy for any feedback I can get, because as the person who mucked around in our text rendering the most lately, I really don't know if most of my decisions are "good". I just go by what I know, but that doesn't mean it's optimal or correct.

For instance cell height (or line height) is currently determined as the font's ascent + descent + lineGap which in case of Consolas is 2398 units, but most if not all glyphs in Consolas have an "advance height" of 2048 units (2048 units are 1em). Should I use the former, which is what others use or should I use the glyph advance height? I really don't know... it makes lines taller by 17%. However it's what is recommended by OpenType: https://learn.microsoft.com/en-us/typography/opentype/spec/recom#stypoascender-stypodescender-and-stypolinegap

In either case, as you might already know, font sizes in conhost aren't specified in "font sizes". They're given in line heights and the font size is determined to fit into that height. So if you specify a "font size" of 20px it'll result in exactly 20px tall cells and the actual font size in px will be some non-integer.

Given that Consolas' ascent + descent + lineGap is 2398 we arrive at a line height of 1.1708984375em. Since you're looking for a line height of 20px you're looking for a font size of 20 / 1.1708984375 == 17.0809px. Converted to points this results in 12.81067556.

Combined with ClearType AA this should result in an identical appearance. Try this config:

"defaults": 
{
    "antialiasingMode": "cleartype",
    "font": 
    {
        "face": "Consolas",
        "size": 12.81067556
    }
},

If there are still gaps, they should be fixed with https://github.com/microsoft/terminal/pull/14099.

Now the question is: How do you put that into our settings model if anything? And could we maybe merge this with my current work on allowing customized line heights?

@lhecker commented on GitHub (Oct 12, 2022): > Apologies if this has already been discussed somewhere. I don't think we have! I'm actually really happy for any feedback I can get, because as the person who mucked around in our text rendering the most lately, I really don't know if most of my decisions are "good". I just go by what I know, but that doesn't mean it's optimal or correct. For instance cell height (or line height) is currently determined as the font's `ascent + descent + lineGap` which in case of Consolas is 2398 units, but most if not all glyphs in Consolas have an "advance height" of 2048 units (2048 units are 1em). Should I use the former, which is what others use or should I use the glyph advance height? I really don't know... it makes lines taller by 17%. However it's what is recommended by OpenType: https://learn.microsoft.com/en-us/typography/opentype/spec/recom#stypoascender-stypodescender-and-stypolinegap In either case, as you might already know, font sizes in conhost aren't specified in "font sizes". They're given in line heights and the font size is determined to fit into that height. So if you specify a "font size" of 20px it'll result in exactly 20px tall cells and the actual font size in px will be some non-integer. Given that Consolas' `ascent + descent + lineGap` is 2398 we arrive at a line height of `1.1708984375em`. Since you're looking for a line height of 20px you're looking for a font size of `20 / 1.1708984375 == 17.0809px`. Converted to points this results in 12.81067556. Combined with ClearType AA this should result in an identical appearance. Try this config: ```json "defaults": { "antialiasingMode": "cleartype", "font": { "face": "Consolas", "size": 12.81067556 } }, ``` If there are still gaps, they should be fixed with https://github.com/microsoft/terminal/pull/14099. Now the question is: How do you put that into our settings model if anything? And could we maybe merge this with my current work on allowing customized line heights?
claunia commented 2026-01-31 06:19:35 +00:00
Author
Owner
Copy Link

@lhecker commented on GitHub (Oct 12, 2022):

BTW there was a discussion about font rendering a while ago over here: https://github.com/microsoft/terminal/issues/13936
Especially in the last few comments it contains some more nuances about why we look different from the rest. As I mentioned in that issue, I believe that what we're doing is technically the right thing to do (especially long term), but that doesn't mean that I'm not urgently looking for any ideas and suggestions what to do better, what to change and how to reconcile old with new, if we do decide that the new approach is in fact better than the old one (long term).

Edit: I'm going to mark it as "question" for now since it's not really a bug (like a crash). We can change it to Issue-Bug/Task/Feature later if it turns out to be something like that. 🙂

@lhecker commented on GitHub (Oct 12, 2022): BTW there was a discussion about font rendering a while ago over here: https://github.com/microsoft/terminal/issues/13936 Especially in the last few comments it contains some more nuances about why we look different from the rest. As I mentioned in that issue, I believe that what we're doing is technically the right thing to do (especially long term), but that doesn't mean that I'm not urgently looking for any ideas and suggestions what to do better, what to change and how to reconcile old with new, if we do decide that the new approach is in fact better than the old one (long term). Edit: I'm going to mark it as "question" for now since it's not really a bug (like a crash). We can change it to Issue-Bug/Task/Feature later if it turns out to be something like that. 🙂
claunia commented 2026-01-31 06:19:36 +00:00
Author
Owner
Copy Link

@alabuzhev commented on GitHub (Oct 12, 2022):

Thank you for the explanation.

Try this config

Thanks, it is really close now (and it only works in Atlas, right?).
However, some extra boldness is still there, especially in horizontal lines, and it makes the picture somewhat heavy visually.

A real world example

compare

How do you put that into our settings model if anything?

Depends what to put:

  • some fine-grained controls to further tweak font size and rendering?
  • a switch between font size and line height?
  • just a single "vintage look" switch?
@alabuzhev commented on GitHub (Oct 12, 2022): Thank you for the explanation. > Try this config Thanks, it is really close now (and it only works in Atlas, right?). However, some extra boldness is still there, especially in horizontal lines, and it makes the picture somewhat heavy visually. <details> <summary>A real world example</summary> ![compare](https://user-images.githubusercontent.com/11453922/195233424-39bef720-ecfe-435d-91d9-b8eaaafb3157.gif) </details> > How do you put that into our settings model if anything? Depends *what* to put: - some fine-grained controls to further tweak font size and rendering? - a switch between font size and line height? - just a single "vintage look" switch?
claunia commented 2026-01-31 06:19:36 +00:00
Author
Owner
Copy Link

@alabuzhev commented on GitHub (Dec 16, 2022):

@lhecker It looks way better in 1.16.3463.0, thank you!

Almost pixel-perfect

compare

@alabuzhev commented on GitHub (Dec 16, 2022): @lhecker It looks way better in 1.16.3463.0, thank you! <details> <summary>Almost pixel-perfect</summary> ![compare](https://user-images.githubusercontent.com/11453922/208183106-ee3fd9f8-4fb8-4c00-959f-ea63d2fc0145.gif) </details>
claunia commented 2026-01-31 06:19:36 +00:00
Author
Owner
Copy Link

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

I'm planning to add a "legacy font size switch" to the settings in the future, allowing you to set a row or line height instead of a font size. I'm just not sure how to best design the switch in the settings UI ¹ or how to store it in the settings.json and I haven't really committed myself to spend time on implementing it just yet. There's a lot of other interesting features I'm working on as well after all, like proper & full Unicode support in all console APIs (and VT), or a "AtlasEngine v2" kind of renderer, which will allow for arbitrarily overlapping glyphs...

¹ Maybe just a checkbox next to the font size?
² I added a cellHeight field in the font object in #14255. Maybe if you set that but leave the font size field empty, we use the cellHeight to derive a pixel-perfect font size from it?

@lhecker commented on GitHub (Dec 16, 2022): I'm planning to add a "legacy font size switch" to the settings in the future, allowing you to set a row or line height instead of a font size. I'm just not sure how to best design the switch in the settings UI ¹ or how to store it in the settings.json and I haven't really committed myself to spend time on implementing it just yet. There's a lot of other interesting features I'm working on as well after all, like proper & full Unicode support in all console APIs (and VT), or a "AtlasEngine v2" kind of renderer, which will allow for arbitrarily overlapping glyphs... ¹ Maybe just a checkbox next to the font size? ² I added a `cellHeight` field in the font object in #14255. Maybe if you set that but leave the font size field empty, we use the `cellHeight` to derive a pixel-perfect font size from it?
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Area-Fonts Area-Rendering Issue-Feature Product-Terminal
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#18623
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?