Combined SGR attributes 1 and 7, "Bold or increased intensity" and "Reverse video" do not render as expected #6471
Labels
Area-Rendering
Text rendering, emoji, complex glyph & font-fallback issues
Issue-Bug
It either shouldn't be doing this or needs an investigation.
Product-Conpty
For console issues specifically related to conpty
Resolution-Duplicate
There's another issue on the tracker that's pretty much the same thing.
Environment
Steps to reproduce
See the attached full capture for more guidance in what the R1C1 reference addresses are indicating.
Expected behavior
With the string
␛[1;7;33m␛[43m R41C8␛[m
, I believe that the foreground and background color output should be the same as␛[33m␛[103m R8C9␛[m
.In this example, if
␛[33m␛[103m
with a video reverse attribute␛[7;33m␛[103m
will invert like it is␛[1;33m␛[43m
, then the same should be true in the reverse.␛[1;33m␛[43m
with the video reverse attribute␛[1;7;33m␛[43m
should invert like it is␛[33m␛[103m
.Actual behavior
Instead of switching the foreground and background colors, it looks like the intensity attribute is applied after switching the two colors.
This has the impact that you cannot see the dark text against the light background because the intensity attribute is applied after the background color is assigned the foreground color, and so when these are in the same color pairing it becomes light on light.
I chose this specific example because under Campbell there is enough contrast between the normal and the intensity colors to clearly demonstrate this problem, but as you can see in the full table the problem exists for all color pairings. You can also see that the reverse colors in a column, the foreground color maintains the same intensity for the entire set of rows, but it would be expected that they would alternate from light to dark between adjoining rows.
The additional test cases which don't have a reference in the table demonstrate that where in the order of attributes that the reverse video attribute is placed should not change the result. This is potentially an ambiguous case in the spec as it could be inferred that setting intensity before or after setting reverse video might have an impact, but I think it is more expressive and likely more how it was intended, that the reverse video attribute can be placed anywhere and reverses the foreground and background colors. An alternate consideration would be that it would actually invert the colors, not just flip the foreground for the background. The ECMA-048 standard actually defines it as "negative image" rather than invert, which is suggestive that flipping the foreground and background colors is the incorrect rendering anyway.
The text was updated successfully, but these errors were encountered: