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

Curly underline is rendered as single #20786

New Issue
Closed
opened 2026-01-31 07:24:02 +00:00 by claunia · 7 comments
claunia commented 2026-01-31 07:24:02 +00:00
Owner
Copy Link

Originally created by @alabuzhev on GitHub (Nov 10, 2023).

Originally assigned to: @tusharsnx on GitHub.

Windows Terminal version

1.20.3131.0

Windows build number

10.0.19045.3448

Other Software

No response

Steps to reproduce

Originally posted in https://github.com/microsoft/terminal/pull/16097#discussion_r1389476524

  1. Set display scaling to 100%

  2. Run OpenConsole or WT

  3. Set font to Consolas

  4. Set font size to:

    • 34 or smaller for OpenConsole, e.g. 20
    • 19 or smaller for WT, e.g. 12

  5. Run something to showcase new underlines, e.g. this script

@echo off

echo 4:1 [4:1;58:2::255:000:000mtest
echo 4:2 [4:2;58:2::255:255:000mtest
echo 4:3 [4:3;58:2::000:255:000mtest
echo 4:4 [4:4;58:2::000:255:255mtest
echo 4:5 [4:5;58:2::255:000:255mtest

pause

- where � is \x1b, or whatever else you might have.

Expected Behavior

Clearly visible underline styles, curly in particular, e.g.:

image

Actual Behavior

Curly is rendered as single in both OpenConsole and WT:

image

OpenConsole also renders double underline as single, which may or may not be related.

Other terminals, e.g. wezterm, seemingly have no issues with even smaller sizes:

image

Technically it's not too small if the wave height is at least 2 pixels:
image

Additionally, OpenConsole with even smaller sizes, e.g. Consolas 15, doesn't render anything but "double" at all:

image

Technical limitations are understandable, but, assuming that the key selling point of this feature is spellchecking, any ugly/incorrect/clipping/overlapping rendering would be better than nothing at all.

Originally created by @alabuzhev on GitHub (Nov 10, 2023). Originally assigned to: @tusharsnx on GitHub. ### Windows Terminal version 1.20.3131.0 ### Windows build number 10.0.19045.3448 ### Other Software _No response_ ### Steps to reproduce _Originally posted in https://github.com/microsoft/terminal/pull/16097#discussion_r1389476524_ 1. Set display scaling to 100% 2. Run OpenConsole or WT 3. Set font to Consolas 4. Set font size to: - 34 or smaller for OpenConsole, e.g. 20 - 19 or smaller for WT, e.g. 12 5. Run something to showcase new underlines, e.g. this script ``` @echo off echo 4:1 [4:1;58:2::255:000:000mtest echo 4:2 [4:2;58:2::255:255:000mtest echo 4:3 [4:3;58:2::000:255:000mtest echo 4:4 [4:4;58:2::000:255:255mtest echo 4:5 [4:5;58:2::255:000:255mtest pause ``` \- where � is \x1b, or whatever else you might have. ### Expected Behavior Clearly visible underline styles, curly in particular, e.g.: ![image](https://github.com/microsoft/terminal/assets/11453922/1ef33c14-04d0-4156-8f86-53750e0f3578) ### Actual Behavior Curly is rendered as single in both OpenConsole and WT: ![image](https://github.com/microsoft/terminal/assets/11453922/4a03c331-1690-4ade-b352-8a7e9353ec43) *OpenConsole also renders double underline as single, which may or may not be related.* ------ Other terminals, e.g. wezterm, seemingly have no issues with even smaller sizes: ![image](https://github.com/microsoft/terminal/assets/11453922/419b48b2-42a0-4a78-b4d2-03aa670b0d76) Technically it's not *too small* if the wave height is at least 2 pixels: ![image](https://github.com/microsoft/terminal/assets/11453922/d6782c1a-2c47-44b7-93e3-02de8fa6fdf8) Additionally, OpenConsole with even smaller sizes, e.g. Consolas 15, doesn't render anything but "double" at all: ![image](https://github.com/microsoft/terminal/assets/11453922/62f55908-737b-4281-9ef2-5b0a737fb9c5) Technical limitations are understandable, but, assuming that the key selling point of this feature is spellchecking, any ugly/incorrect/clipping/overlapping rendering would be better than nothing at all.
claunia commented 2026-01-31 07:24:05 +00:00
Author
Owner
Copy Link

@tusharsnx commented on GitHub (Nov 10, 2023):

There are two issues in this Issue

1. Curly line drawn as Singly line

Admittedly, I've a high dpi screen which I use at 175% scaling. I guess the threshold we kept for curly underlines can be fine tuned for 100% display scaling. Something that works for 100% should work for 175% as well 🙂

Can someone try a different value for minCurlyLinePeakHeight, and see which one works better at 100% display scaling?

AtlasEngine (WT)

d14524cd4c/src/renderer/atlas/BackendD3D.cpp (L311-L313)

GDI (Conhost)

d14524cd4c/src/renderer/gdi/state.cpp (L410-L432)

In GDI, we have two conditions to check before drawing curly underline:

  1. Underline width is atleast 1px.
  2. Space between cell bottom and underline position is atleast MinCurlyLinePeakHeight (2px).

2. Underlines not visible at smaller font-sizes in Conhost

Additionally, OpenConsole with even smaller sizes, e.g. Consolas 15, doesn't render anything but "double" at all:

I guess the underline offset we're calculating is making underlines to be drawn below the cell bottom, effectively making them not visible at all. A fix could be to clamp the offset within cell boundary🤔 (For me, this happens at font-size 9px with Consolas.)

@tusharsnx commented on GitHub (Nov 10, 2023): There are two issues in this Issue ### 1. Curly line drawn as Singly line Admittedly, I've a high dpi screen which I use at 175% scaling. I guess the threshold we kept for curly underlines can be fine tuned for 100% display scaling. Something that works for 100% should work for 175% as well 🙂 Can someone try a different value for `minCurlyLinePeakHeight`, and see which one works better at 100% display scaling? AtlasEngine (WT) https://github.com/microsoft/terminal/blob/d14524cd4cc4970bb1b6456f9667e2dd661b9854/src/renderer/atlas/BackendD3D.cpp#L311-L313 GDI (Conhost) https://github.com/microsoft/terminal/blob/d14524cd4cc4970bb1b6456f9667e2dd661b9854/src/renderer/gdi/state.cpp#L410-L432 In GDI, we have two conditions to check before drawing curly underline: 1. Underline width is atleast 1px. 2. Space between cell bottom and underline position is atleast `MinCurlyLinePeakHeight` (2px). ### 2. Underlines not visible at smaller font-sizes in Conhost >Additionally, OpenConsole with even smaller sizes, e.g. Consolas 15, doesn't render anything but "double" at all: I guess the underline offset we're calculating is making underlines to be drawn below the cell bottom, effectively making them not visible at all. A fix could be to clamp the offset within cell boundary🤔 (For me, this happens at font-size 9px with Consolas.)
claunia commented 2026-01-31 07:24:05 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Nov 10, 2023):

The line offsets should have already been set to their correct positions based on the provided font metrics in the GdiEngine::UpdateFont method. The problem is that we've now added an additional offset at render time here:

d14524cd4c/src/renderer/gdi/paint.cpp (L622-L626)

That's almost certainly wrong. Even if if wasn't pushing the offsets out of range, it doesn't make sense to be altering the value here. What was the reason for this change?

Edit: I see now it's probably because the single and double underline are now rendered with LineTo calls rather than PatBlt. But there must be something wrong with that calculation, because the original line offset should definitely have been in range. Also, if we need that additional half-width offset, that calculation should really be done in advance in the UpdateFont method. There's surely no need to keep recalculating it every time an underline is rendered?

@j4james commented on GitHub (Nov 10, 2023): The line offsets should have already been set to their correct positions based on the provided font metrics in the `GdiEngine::UpdateFont` method. The problem is that we've now added an additional offset at render time here: https://github.com/microsoft/terminal/blob/d14524cd4cc4970bb1b6456f9667e2dd661b9854/src/renderer/gdi/paint.cpp#L622-L626 That's almost certainly wrong. Even if if wasn't pushing the offsets out of range, it doesn't make sense to be altering the value here. What was the reason for this change? Edit: I see now it's probably because the single and double underline are now rendered with `LineTo` calls rather than `PatBlt`. But there must be something wrong with that calculation, because the original line offset should definitely have been in range. Also, if we need that additional half-width offset, that calculation should really be done in advance in the `UpdateFont` method. There's surely no need to keep recalculating it every time an underline is rendered?
claunia commented 2026-01-31 07:24:05 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Nov 10, 2023):

Also, assuming you're looking at this code again, note that the underlineWidth should never be less than 1. We've got a check for that here:

d14524cd4c/src/renderer/gdi/state.cpp (L379-L383)

So I think the test below should never be necessary.

d14524cd4c/src/renderer/gdi/state.cpp (L409-L413)

@j4james commented on GitHub (Nov 10, 2023): Also, assuming you're looking at this code again, note that the `underlineWidth` should never be less than 1. We've got a check for that here: https://github.com/microsoft/terminal/blob/d14524cd4cc4970bb1b6456f9667e2dd661b9854/src/renderer/gdi/state.cpp#L379-L383 So I think the test below should never be necessary. https://github.com/microsoft/terminal/blob/d14524cd4cc4970bb1b6456f9667e2dd661b9854/src/renderer/gdi/state.cpp#L409-L413
claunia commented 2026-01-31 07:24:05 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Nov 13, 2023):

I'm gonna pull this one out of the triage queue and assign it to you, Tushar! Let me know if you have any objections. Thanks for working on underlines!

@DHowett commented on GitHub (Nov 13, 2023): I'm gonna pull this one out of the triage queue and assign it to you, Tushar! Let me know if you have any objections. Thanks for working on underlines!
claunia commented 2026-01-31 07:24:05 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Dec 8, 2023):

Hey @tusharsnx, I've got a crazy plan... but it might need this bug fixed for me to pull it off 😁

(are you able to look into it?)

@DHowett commented on GitHub (Dec 8, 2023): Hey @tusharsnx, I've got a crazy plan... but it might need this bug fixed for me to pull it off 😁 (are you able to look into it?)
claunia commented 2026-01-31 07:24:05 +00:00
Author
Owner
Copy Link

@tusharsnx commented on GitHub (Dec 8, 2023):

@DHowett

(are you able to look into it?)

Almost ready! 🙂

@tusharsnx commented on GitHub (Dec 8, 2023): @DHowett > (are you able to look into it?) Almost ready! 🙂
claunia commented 2026-01-31 07:24:06 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Dec 8, 2023):

Okay I definitely thought that's what you meant on Twitter, I just had to make sure!

@DHowett commented on GitHub (Dec 8, 2023): Okay I definitely thought that's what you meant on Twitter, I just had to make sure!
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-Rendering In-PR Issue-Bug Needs-Tag-Fix Priority-2 Product-Conhost 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#20786
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?