Add an option to suppress bold fonts (render as normal weight) for 32-bit colors

[iBug]

Description of the new feature

On hi-res displays like 4K, normal font weight can be much more legible for some users. It's therefore desirable to allow the terminal to disregard applications' request for bold font and instead render the normal font weight for all characters.

This feature request is exactly the same as this iTerm2 option:

Comparison (note the RUBY_PLATFORM variable):

Windows Terminal (current)	iTerm2

To reproduce:

• Set TERM=xterm-256color
• Print an escape sequence using both VT intense style (CSI 1 m) and 32-bit color:
• echo -e '\x1B[1m\x1B[38;2;255;255;0mAAAA'
• Verify the text AAAA comes in bold font.

This happens even if intenseTextStyle is set to bright.

In particular, using the CSI 38;5;<n>m sequence, text comes out as normal weight for 0 < n < 16, and bold weight for n >= 16 (i.e. outside the standard 16 colors palette range).

Proposed technical implementation details

No response

[DHowett]

We have such an option.

[DHowett]

(We just call it "intense text", because that's the VT name for it!)

[iBug]

Dustin L. Howett (@DHowett) Can you elaborate? If you open a Shell or Python script in Vim with termguicolors enabled, you can see bold text even if intenseTextStyle is set to bright only. So either there's an alternative thing to VT intense (ESC [ 1 m), or Windows Terminal is failing to catch something.

[iBug]

Dustin L. Howett (@DHowett) I think this is a bug. It can be reproduced by combining CSI 1 m and CSI 38 32-bit color sequence.

• Bright text only: echo -e '\x1B[1m\x1B[33mAAAA'
• Bold text: echo -e '\x1B[1m\x1B[38;2;255;255;0mAAAA'

For CSI 38;5 sequence, the text comes out bold if and only if the last argument is at least 16 (e.g. \x1B[1m\x1B[38;5;226mAAAA).

[DHowett]

You're not wrong! This was a decision we made in #18903 to fix #18284, citing user assertions like this:

3. FWIW, it's not unusual for certain services to specifically transition to 256-colors even for the original 16 colors in order to signal that it wants bold text without dealing with the ambiguity of bold vs. bright. So the lack of support in windows terminal is a wrench in the works.

Right now, it's by design. We haven't gotten significant pushback on that decision but if enough folks hate it I'm sure we'd be willing to add an option. But for right now... eh. Each one of these knobs we add makes it harder for applications to reliably figure out what we're gonna do or what terminal we're going to act most like.

[iBug]

Dustin L. Howett (@DHowett) Any chance this gets reopened for collecting user feedback? If you don't keep an issue open, chances are you're not receiving the true level of users' opinions due to lack of response channels or alike.

[zadjii-msft]

People can make their voices heard even on closed issues. It's not like the comments section goes away. But as we're not planning work for this now, we'd rather close it out.