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

Windows Terminal when moved to a scaled display has wider character spacing #22064

New Issue
Closed
opened 2026-01-31 08:02:29 +00:00 by claunia · 3 comments
claunia commented 2026-01-31 08:02:29 +00:00
Owner
Copy Link

Originally created by @abhbh on GitHub (Aug 8, 2024).

Windows Terminal version

1.20.11781.0

Windows build number

10.0.22631.3958

Other Software

No response

Steps to reproduce

  1. Open Windows Terminal on primary display (scaling 100%)
  2. Move the terminal window to another screen which has different scaling (125%) than the curent display
  3. Observe that the characters have widened spacing.
  4. Move the terminal back to the first display

The behaviour is not seen with in any other application like Visual Studio Code, Sublime Text, Git Bash, Notepad etc. (Tested with the same font at same size)

Expected Behavior

If a window is moved to a display with different scaling setting, minor difference in font size and smoothing is expected but not change in character spacing width.

Actual Behavior

After moving the window to the display with different scaling, character spacing width increases.

I have attached images from Notepad and Terminal. All other applications (including Electron and old Win32 apps) behave similarly to Notepad.

Font used in screenshot: Cascadia Mono 14. The behaviour is similar with any other font. I have tried Cascadia Code, Consolas, Lucida Console and Courier New.

In the first image from the main display, the character grid of Cascadia Code aligns between two apps. 18 characters (the prompt) take the same space in both Notepad and Terminal.
Screenshot 2024-08-08 235419

In the second image from the scaled display, the same 18 characters (the prompt) now take 20 character grid worth of space of Notepad.
Screenshot 2024-08-08 235525

For brevity:
comparison100
comparison125

Originally created by @abhbh on GitHub (Aug 8, 2024). ### Windows Terminal version 1.20.11781.0 ### Windows build number 10.0.22631.3958 ### Other Software _No response_ ### Steps to reproduce 1. Open Windows Terminal on primary display (scaling 100%) 2. Move the terminal window to another screen which has different scaling (125%) than the curent display 3. Observe that the characters have widened spacing. 4. Move the terminal back to the first display The behaviour is not seen with in any other application like Visual Studio Code, Sublime Text, Git Bash, Notepad etc. (Tested with the same font at same size) ### Expected Behavior If a window is moved to a display with different scaling setting, minor difference in font size and smoothing is expected but not change in character spacing width. ### Actual Behavior After moving the window to the display with different scaling, character spacing width increases. I have attached images from Notepad and Terminal. All other applications (including Electron and old Win32 apps) behave similarly to Notepad. > Font used in screenshot: Cascadia Mono 14. The behaviour is similar with any other font. I have tried Cascadia Code, Consolas, Lucida Console and Courier New. In the first image from the main display, the character grid of Cascadia Code aligns between two apps. 18 characters (the prompt) take the same space in both Notepad and Terminal. ![Screenshot 2024-08-08 235419](https://github.com/user-attachments/assets/e6995a90-cc03-493a-b911-f90a49e7f352) In the second image from the scaled display, the same 18 characters (the prompt) now take 20 character grid worth of space of Notepad. ![Screenshot 2024-08-08 235525](https://github.com/user-attachments/assets/dcc8158d-1902-4d09-a537-4663a512a588) For brevity: ![comparison100](https://github.com/user-attachments/assets/7665e282-ae5d-4630-8b7b-027e0cc02019) ![comparison125](https://github.com/user-attachments/assets/c236d66d-9091-46cb-94f0-6623404a77f6)
claunia added the Needs-TriageIssue-Bug labels 2026-01-31 08:02:29 +00:00
claunia commented 2026-01-31 08:02:30 +00:00
Author
Owner
Copy Link

@lhecker commented on GitHub (Aug 8, 2024):

Our text renderer currently only supports whole pixel alignments for cells. Both 100% and 125% display scale are low resolution with just a 2px size difference between each other. (In an ideal world where Microsoft was less lenient on its partners, we'd already be swimming in 200% scale displays... 🥲) In your case, this issue comes down to the glyph being just 0.17px too wide at 125% scale which when rounded results it in being 1px "too wide". But to be fair, we're rounding to nearest, not up, and so I'm not sure if we're behaving incorrectly per se.

Notepad uses a glyph rendering and layout that simulates old GDI with strong hinting. So far, we didn't want to replicate that look as it unnaturally distorts the glyph shape. Our text renderer applies a softer hinting and always uses the font's design metrics wherever it can.

In my opinion supporting GDI-style rendering is not the right way forward, but rather to add support for subpixel positioning. See #15805. I'd love to address this myself, but I currently don't plan on working on it in the near term since other issues have received more interest by our users (infinite scrollback for instance). It's still an issue that's dear to my heart, because it's important for a visually consistent glyph spacing even at HiDPI.

However, you said that you tested this in VS Code and I believe you may have tested this incorrectly. If you want to test a 14pt font in VS Code you have to convert the font size to px, because that's what VS Code expects. Simply multiply by 1.333333… to do so (= 18.666666…). If you do that, the width of the run in VS Code will be almost identical to Windows Terminal. The only difference is that VS Code (like any Chromium application) supports subpixel positioning and so it'll be slightly shorter at any display scale.

Here's an image at 125% display scale, 14pt = 18.666666px Cascadia Mono in (top to bottom) VS Code, Windows Terminal, and Notepad:

image

As you can see, the first two are fairly close in their widths. If you zoom in, you may additionally notice...

VS Code's subpixel positioning (it's subtle):
image

and GDI's hinting:
image

In short, I believe the right way forward is to do what Chromium does, which is tracked in #15805.

@lhecker commented on GitHub (Aug 8, 2024): Our text renderer currently only supports whole pixel alignments for cells. Both 100% and 125% display scale are low resolution with just a 2px size difference between each other. (In an ideal world where Microsoft was less lenient on its partners, we'd already be swimming in 200% scale displays... 🥲) In your case, this issue comes down to the glyph being just 0.17px too wide at 125% scale which when rounded results it in being 1px "too wide". But to be fair, we're rounding to nearest, not up, and so I'm not sure if we're behaving incorrectly per se. Notepad uses a glyph rendering and layout that simulates old GDI with strong hinting. So far, we didn't want to replicate that look as it unnaturally distorts the glyph shape. Our text renderer applies a softer hinting and always uses the font's design metrics wherever it can. In my opinion supporting GDI-style rendering is not the right way forward, but rather to add support for subpixel positioning. See #15805. I'd love to address this myself, but I currently don't plan on working on it in the near term since other issues have received more interest by our users (infinite scrollback for instance). It's still an issue that's dear to my heart, because it's important for a visually consistent glyph spacing even at HiDPI. However, you said that you tested this in VS Code and I believe you may have tested this incorrectly. If you want to test a 14pt font in VS Code you have to convert the font size to px, because that's what VS Code expects. Simply multiply by 1.333333… to do so (= 18.666666…). If you do that, the width of the run in VS Code will be almost identical to Windows Terminal. The only difference is that VS Code (like any Chromium application) supports subpixel positioning and so it'll be slightly shorter at any display scale. Here's an image at 125% display scale, 14pt = 18.666666px Cascadia Mono in (top to bottom) VS Code, Windows Terminal, and Notepad: ![image](https://github.com/user-attachments/assets/149e8da2-7f93-4e25-8a9f-2131292fb6b9) As you can see, the first two are fairly close in their widths. If you zoom in, you may additionally notice... VS Code's subpixel positioning (it's subtle): ![image](https://github.com/user-attachments/assets/8b1c4cba-6dc8-4f38-97d5-68c09b8e8180) and GDI's hinting: ![image](https://github.com/user-attachments/assets/ae19456f-256c-47a7-b2ff-3ff639db3cf2) In short, I believe the right way forward is to do what Chromium does, which is tracked in #15805.
claunia commented 2026-01-31 08:02:30 +00:00
Author
Owner
Copy Link

@abhbh commented on GitHub (Aug 12, 2024):

Yeah. I experimented more with different font sizes and font families. I can largely confirm what you said.

#15805

Microsoft has largely moved away from subpixel rendering in their newer modern apps so I don't expect that to happen. For my next upgrade, I hope that market has good display options which I can run at 200%. Those are so rare outside the Apple world. If not that, going to a denser display will atleast make the issue less noticeable.

@abhbh commented on GitHub (Aug 12, 2024): Yeah. I experimented more with different font sizes and font families. I can largely confirm what you said. > #15805 Microsoft has largely moved away from subpixel rendering in their newer modern apps so I don't expect that to happen. For my next upgrade, I hope that market has good display options which I can run at 200%. Those are so rare outside the Apple world. If not that, going to a denser display will atleast make the issue less noticeable.
claunia commented 2026-01-31 08:02:31 +00:00
Author
Owner
Copy Link

@lhecker commented on GitHub (Aug 12, 2024):

Microsoft has largely moved away from subpixel rendering in their newer modern apps so I don't expect that to happen.

To clarify, subpixel rendering, and subpixel positioning are two different things. Subpixel positioning is just about having a precision of <1px when placing glyphs on the screen. This is important even for HiDPI displays. As far as I'm aware all state-of-the-art text renderers have subpixel positioning.

@lhecker commented on GitHub (Aug 12, 2024): > Microsoft has largely moved away from subpixel rendering in their newer modern apps so I don't expect that to happen. To clarify, subpixel rendering, and subpixel positioning are two different things. Subpixel positioning is just about having a precision of <1px when placing glyphs on the screen. This is important even for HiDPI displays. As far as I'm aware all state-of-the-art text renderers have subpixel positioning.
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 Issue-Bug Needs-Triage
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#22064
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?