[James Holderness (j4james)]

Summary of the Pull Request

This PR adds support for the SGR 2 escape sequence, which enables the
ANSI faint graphic rendition attribute. When a character is output
with this attribute set, it uses a dimmer version of the active
foreground color.

PR Checklist

• Closes Add support for SGR 2 Faint #6703
• CLA signed.
• Tests added/passed
• Documentation updated.
• Schema updated.
• I've discussed this with core contributors already. Issue number where discussion took place: Add support for SGR 2 Faint #6703

Detailed Description of the Pull Request / Additional comments

There was already an ExtendedAttributes::Faint flag in the
TextAttribute class, but I needed to add SetFaint and IsFaint
methods to access that flag, and update the SetGraphicsRendition
methods of the two dispatchers to set the attribute on receipt of the
SGR 2 sequence. I also had to update the existing SGR 22 handler to
reset Faint in addition to Bold, since they share the same reset
sequence. For that reason, I thought it a good idea to change the name
of the SGR 22 enum to NotBoldOrFaint.

For the purpose of rendering, I've updated the
TextAttribute::CalculateRgbColors method to return a dimmer version of
the foreground color when the Faint attribute is set. This is simply
achieved by dividing each color component by two, which produces a
reasonable effect without being too complicated. Note that the Faint
effect is applied before Reverse Video, so if the output it reversed,
it's the background that will be faint.

The only other complication was the update of the Xterm256Engine in
the VT renderer. As mentioned above, Bold and Faint share the same
reset sequence, so to forward that state over conpty we have to go
through a slightly more complicated process than with other attributes.
We first check whether either attribute needs to be turned off to send
the reset sequence, and then check if the individual attributes need to
be turned on again.

Validation

I've extended the existing SGR unit tests to cover the new attribute in
the AdapterTest, the ScreenBufferTests, and the VtRendererTest,
and added a test to confirm the color calculations when Faint is set
in the TextAttributeTests.

I've also done a bunch of manual testing with all the different VT color
types and confirmed that our output is comparable to most other
terminals.

[Dustin L. Howett (DHowett)]

This is great.

I wonder if, if we ever do get perceptual grading going, there's value in making faint more faint (=harder to perceive) rather than just darker.

Given that darkening is comparable to other terminal emulators, it's more of a curiosity than a desire. 😄

Thanks for doing this.

[James Holderness (j4james)]

Btw, here are a couple of screenshots comparing how other terminals handle this. From left to right, top to bottom: XTerm, VTE (Gnome Terminal), Mintty, and then us. In each case I've got a color test pattern rendered with normal attributes first, and with a faint version below. I think XTerm and VTE are a bit brighter than us, but Mintty looks almost identical. The overall effect is about the same though.

[Mike Griese (zadjii-msft)]

Fantastic as always. Thanks!

[Deleted user (ghost)]

Hello Dustin L. Howett (@DHowett)!

Because this pull request has the AutoMerge label, I will be glad to assist with helping to merge this pull request once all check-in policies pass.

p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (@msftbot) and give me an instruction to get started! Learn more here.

[Deleted user (ghost)]

🎉Windows Terminal Preview v1.2.2022.0 has been released which incorporates this pull request.:tada:

Handy links:

• Release Notes
• Store Download