starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-03 21:25:34 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

Preview renders shorter, vertically compressed characters #20124

New Issue
Closed
opened 2026-01-31 07:04:16 +00:00 by claunia · 6 comments
claunia commented 2026-01-31 07:04:16 +00:00
Owner
Copy Link

Originally created by @alexis-m on GitHub (Jun 21, 2023).

Originally assigned to: @lhecker on GitHub.

Windows Terminal version

1.18.1462.0

Windows build number

10.0.19045.3086

Other Software

Stock PowerShell

Steps to reproduce

4K monitor (3840x2160), scale 150%.
Default Windows PowerShell profile -- change font size to 9 points.

Expected Behavior

No response

Actual Behavior

Compared to latest stable version (1.17.11461.0), the preview version (1.18.1462.0) renders shorter, vertically compressed characters. It is very obvious with characters a, e, s. The difference (seems to be only 1 pixel) makes it noticeably harder to read the text where there is a lot of it.

font_1_stable_1 17 11461 0 font_2_preview_1 18 1462 0
Originally created by @alexis-m on GitHub (Jun 21, 2023). Originally assigned to: @lhecker on GitHub. ### Windows Terminal version 1.18.1462.0 ### Windows build number 10.0.19045.3086 ### Other Software Stock PowerShell ### Steps to reproduce 4K monitor (3840x2160), scale 150%. Default Windows PowerShell profile -- change font size to 9 points. ### Expected Behavior _No response_ ### Actual Behavior Compared to latest stable version (1.17.11461.0), the preview version (1.18.1462.0) renders shorter, vertically compressed characters. It is very obvious with characters `a`, `e`, `s`. The difference (seems to be only 1 pixel) makes it noticeably harder to read the text where there is a lot of it. <img width="500" alt="font_1_stable_1 17 11461 0" src="https://github.com/microsoft/terminal/assets/7037205/a6c18d11-96cd-4b25-92d6-957c1cfdc5fb"> <img width="500" alt="font_2_preview_1 18 1462 0" src="https://github.com/microsoft/terminal/assets/7037205/236bcecb-666f-4aed-a60b-f89a12026209">
claunia commented 2026-01-31 07:04:17 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Jun 21, 2023):

@lhecker interesting - I thought glyph compression was a thing that DX did but Atlas didn't. Do you know what font sizing handling change would be responsible for this?

Would changing the cellHeight help?

@DHowett commented on GitHub (Jun 21, 2023): @lhecker interesting - I thought glyph compression was a thing that DX did but Atlas didn't. Do you know what font sizing handling change would be responsible for this? Would changing the cellHeight help?
claunia commented 2026-01-31 07:04:18 +00:00
Author
Owner
Copy Link

@lhecker commented on GitHub (Jun 21, 2023):

Yeah b6e6dd861d changed the computation of line heights from

round(ascent) + round(descent + lineGap)

to

round(ascent + descent + lineGap)

(src/renderer/atlas/AtlasEngine.api.cpp line 635 and following.)

I don't know which of the two approaches is more correct. IIRC I did it to make the baseline calculation work correctly a little later in that file. Thinking about it again, I feel like I should change it to

round(ascent + lineGap / 2) + round(descent + lineGap / 2)

I also use 4K at 150% so I'll just test it out myself.

@lhecker commented on GitHub (Jun 21, 2023): Yeah b6e6dd861d165afb7f8bc9fe031a89ab615a3efb changed the computation of line heights from ``` round(ascent) + round(descent + lineGap) ``` to ``` round(ascent + descent + lineGap) ``` (`src/renderer/atlas/AtlasEngine.api.cpp` line 635 and following.) I don't know which of the two approaches is more correct. IIRC I did it to make the `baseline` calculation work correctly a little later in that file. Thinking about it again, I feel like I should change it to ``` round(ascent + lineGap / 2) + round(descent + lineGap / 2) ``` I also use 4K at 150% so I'll just test it out myself.
claunia commented 2026-01-31 07:04:18 +00:00
Author
Owner
Copy Link

@lhecker commented on GitHub (Jun 21, 2023):

@alexis-m Oh right and for the meantime you can set the cellHeight property. After opening settings.json you can do it like this:

{
    "profiles":
    {
        "defaults":
        {
            "font":
            {
                "cellHeight": "10px" /* (or pt, etc., just like in CSS) */
            }
        }
    }
}
@lhecker commented on GitHub (Jun 21, 2023): @alexis-m Oh right and for the meantime you can set the `cellHeight` property. After opening settings.json you can do it like this: ```js { "profiles": { "defaults": { "font": { "cellHeight": "10px" /* (or pt, etc., just like in CSS) */ } } } } ```
claunia commented 2026-01-31 07:04:18 +00:00
Author
Owner
Copy Link

@alexis-m commented on GitHub (Jun 22, 2023):

@lhecker, hm, cellHeight seems to be changing the line height (more empty vertical space) but not the characters' size.
Here is how it looks with a dramatically larger cellHeight

"font": 
{
    "size": 9.0,
    "cellHeight": "20pt"
},

image

@alexis-m commented on GitHub (Jun 22, 2023): @lhecker, hm, `cellHeight` seems to be changing the line height (more empty vertical space) but not the characters' size. Here is how it looks with a dramatically larger cellHeight ``` "font": { "size": 9.0, "cellHeight": "20pt" }, ``` ![image](https://github.com/microsoft/terminal/assets/7037205/a0d15254-3fa7-451c-a3c1-ce0b9b6c7978)
claunia commented 2026-01-31 07:04:18 +00:00
Author
Owner
Copy Link

@lhecker commented on GitHub (Jun 22, 2023):

Ooooh... now I get it. I misunderstood the issue as a difference in behavior between the "AtlasEngine" text renderer in 1.17 and 1.18, but you're actually saying there's a difference between the default behavior in stable (1.17) and the default behavior in preview (1.18) Windows Terminal.

Yes, that difference is actually intentional. The default text renderer in stable is called "DxRenderer" and when you tell it "9pt" it actually pretty much never draws at exactly 9pt. It uses the given font size to compute the column width of the terminal, and from that it computes the actual font size, which might be something like 9.5pt for instance.
The new text renderer in preview will always draw text at the precise size you tell it to, without any rounding, modifications or anything else.

The good news is that you can easily restore the old behavior! Just set your font size to 9.7. It'll look exactly like it used to. 🙂
Please let me know if that works for you, or if you have any questions or suggestions for any further improvements.

@lhecker commented on GitHub (Jun 22, 2023): Ooooh... now I get it. I misunderstood the issue as a difference in behavior between the "AtlasEngine" text renderer in 1.17 and 1.18, but you're actually saying there's a difference between the _default_ behavior in stable (1.17) and the default behavior in preview (1.18) Windows Terminal. Yes, that difference is actually intentional. The default text renderer in stable is called "DxRenderer" and when you tell it "9pt" it actually pretty much never draws at exactly 9pt. It uses the given font size to compute the column width of the terminal, and from _that_ it computes the actual font size, which might be something like 9.5pt for instance. The new text renderer in preview will always draw text at the precise size you tell it to, without any rounding, modifications or anything else. The good news is that you can easily restore the old behavior! Just set your font size to 9.7. It'll look exactly like it used to. 🙂 Please let me know if that works for you, or if you have any questions or suggestions for any further improvements.
claunia commented 2026-01-31 07:04:18 +00:00
Author
Owner
Copy Link

@alexis-m commented on GitHub (Jun 22, 2023):

Ha! Setting font size to 9.7 in preview 1.18 indeed gave exactly the same column x rows layout as with font size 9 in the stable 1.17. Thanks!

Interestingly, even though the columns and the rows are the same, the characters are taller now 😄 I think I like it more this way. But here is an example just in case.
font_3_stable
font_4_preview

@alexis-m commented on GitHub (Jun 22, 2023): Ha! Setting font size to 9.7 in preview 1.18 indeed gave exactly the same column x rows layout as with font size 9 in the stable 1.17. Thanks! Interestingly, even though the columns and the rows are the same, the characters are taller now 😄 I think I like it more this way. But here is an example just in case. <img width="210" alt="font_3_stable" src="https://github.com/microsoft/terminal/assets/7037205/9e566b99-6485-4a33-bbf8-b136134dbb16"> <img width="210" alt="font_4_preview" src="https://github.com/microsoft/terminal/assets/7037205/a4968a75-99fc-4211-b9d2-ac91e5380cd8">
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-AtlasEngine Issue-Question Needs-Attention Needs-Tag-Fix Resolution-Answered
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#20124
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?