Poor contrast of progress bars when Automatically adjust lightness of indistinguishable text is enabled

[chrisrodrigue]

Windows Terminal version

1.22.10352.0

Windows build number

10.0.22631.4890

Other Software

uv 0.6.2

Steps to reproduce

See astral-sh/uv#11727

I think this is likely an issue with Windows Terminal and not an issue with uv.

Expected Behavior

Actual Behavior

It seems that Automatically adjust lightness of indistinguishable text has the opposite effect on certain progress bars.

[lhecker]

(Side note: Looking at these screenshots, I'm impressed how well our algorithm predicted the brightened color...)

Do you have a suggestion how we could otherwise handle this? It's difficult for me to think of something that would work in the general case (i.e. even outside of your specific example), as it would require the terminal to be content-aware and recognize that this is a progress bar in the first place. Perhaps I'm overlooking an obvious solution...

[lhecker]

The ideal solution I can think of is to group all colors in the viewport, sort them descending by frequency, assign the first one its original color and then nudge every other color to fulfill a given min. distance to every preceding color. Not entirely sure how to do that in a scalable way though.

Edit: Barnes-Hut simulation or Fast Multipole Method?

[j4james]

The ideal solution I can think of is to group all colors in the viewport, sort them descending by frequency, assign the first one its original color and then nudge every other color to fulfill a given min. distance to every preceding color.

Performance issues aside, surely that's just going to result in the screen flickering wildly as the content changes and different colors appear and disappear? Imagine scrolling through some source code in an editor with syntax highlighting for example. I think something like that is almost certain to generate bug reports.

I know nobody wants to hear this, but honestly the best solution is to pick a color scheme that doesn't require magic adjustments to make it readable.

[chrisrodrigue]

Would it be a big ask to make the color schemes readable by default?

[lhecker]

Windows Terminal Preview 1.23 has a new color scheme named "Ottosson" with which we're trying to improve the situation. Personally, I don't think it's fully fixable, because e.g. dark green on dark cyan is just fundamentally hard to read (cyan has a narrow chromatic "breadth" and its hue is close to green), but I do think the new scheme is at least a step forward. And not putting dark green on dark cyan should be common sense by application authors anyway IMO. Here's what it looks like compared to Campbell: #18502 (comment)

[DHowett]

Would it be a big ask to make the color schemes readable by default?

You'd be surprised. There are 17 possible foreground colors. No, it is not broadly possible to make all 272 combinations 100% readable when they're put directly next to each other (using glyphs that look like a line, to boot!) while maintaining their identity as the actual colors they're supposed to represent and making them pleasant to look at at the same time.

[zadjii-msft]

DAYS SINCE I'VE REGRETTED SHIPPING SOLARIZED: 736 0

[chrisrodrigue]

On further inspection, this isn't an issue with the "adjust lightness" setting.

It also isn't an issue with the Solarized theme, which has been implemented in many other terminals and editors without readability issues and is considered to be the most important color scheme in computer history.

This actually seems be a bug with the color value used for text prefixed by one or more hyphens. Using the bright black value for short/long options is a poor choice here and it doesn't seem to be configurable by the user.

For what it's worth, vscode utilizes green for hyphenated text.

One might have expected some internal coherence among Microsoft products, especially when it comes to UIs and themes.

The only themes common to both products are Dark+ and Solarized, and they aren't even implemented the same way...

[chrisrodrigue]

But this is also a known issue.

[lhecker]

This actually seems be a bug with the color value that Windows Terminal uses for text prefixed by one or more hyphens. [...]
For what it's worth, vscode utilizes green for hyphenated text.

...are you talking about the colors that PowerShell uses? That's not something the terminal controls. If you want to change what it uses, you can use a command like this in your Microsoft.PowerShell_profile.ps1:

Set-PSReadLineOption -Colors @{ "Command"="`e[32m" }

32 is the VT color code for "green". Here's a list: https://en.wikipedia.org/wiki/ANSI_escape_code#3-bit_and_4-bit
You can read more about that here: https://learn.microsoft.com/en-us/powershell/module/psreadline/set-psreadlineoption?view=powershell-7.5#-colors

Why PowerShell in the terminal doesn't use the same colors as the PowerShell syntax highlighter in VS Code is not known to me, but you could raise that as an issue over at https://github.com/PowerShell/PowerShell

But this is also a known issue.

You're right that Windows Terminal does not match Explorer exactly, but it's fairly close:

The increased height of the titlebar is part of the UI framework "design language" and may change if we ever switch to another one.

[chrisrodrigue]

@lhecker Thanks for the professional/thoughtful response and sorry for any snark...

It looks like PowerShell colors in the vscode integrated terminal are different than the ones shown in Windows Terminal.

I wonder how they are overriding the PowerShell colors, and if it might be possible or beneficial in Windows Terminal.

[chrisrodrigue]

For a better comparison:

[lhecker]

I believe this may be happening, because their terminal has contrast enhancement for text enabled by default. The setting is called terminal.integrated.minimumContrastRatio and if you set it to 1 it should disable the feature. I tried it just now and the arguments are basically invisible (this says foo -bar):

[chrisrodrigue]

Interesting, it looks like that is motivated by these accessibility guidelines which sets 4.5 as the minimum.

Could this be an opportunity to add that setting?

[lhecker]

"Automatically adjust lightness of indistinguishable text" is meant to be our equivalent. Making the strength of our algorithm adjustable is tracked here: #14940
I just marked it up as Help-Wanted, because we're a little short-staffed and probably won't get to this any time soon. This comment mentions where the change would need to take place: #14940 (comment)

[carlos-zamora]

Nice discussion all! Yeah, we're going to mark this as a /duplicate of #14940. That tracks making the setting adjustable.

[microsoft-github-policy-service]

Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report!