Unexpected behaviour when bold and reverse ANSI attributes are combined

[j4james]

Windows build number: [Version 10.0.16299.248]

The ANSI sequence \033[1;7m sets both the bold (increased intensity) attribute and the negative/reverse attribute, but when those attributes are combined, I'd expected the increased intensity to apply to the final foreground color (i.e. after the colors have been reversed), so you'd get "bright" black on regular white, rather than black on bright white.

The former behaviour is what I see under MS-DOS (with ANSI.SYS) and the Linux console. But the Windows console applies the increased intensity to the foreground before the colors are reversed, so you end up with black on bright white instead.

Test case (from a bash shell): printf "\033[0;1;7m ACTUAL \033[0;1;30;47m EXPECTED \033[m\n"

I realise things are more complicated under Windows, since many more colors are supported, so it's possible this is intentional behaviour. However, I thought it best to bring it up in case it is a bug.

Also note that I'm referring to the behaviour as seen in a fresh console window. Things get weirder once you apply a 24-bit color and trigger the strange mode reported in issue #78. I'm not sure if the fix for that issue is likely to effect this behaviour too.

[zadjii-msft]

Might be related to #136

I'll investigate.

[zadjii-msft]

Hey wadda you know, this was in fact a dupe of #136. It's already in code review!

[j4james]

I have the October update now (the ver command is reporting Version 10.0.17763.194), but this issue still appears broken to me. This is what my test case looks like in the WSL bash console compared with an Ubuntu virtual terminal:

Is that behaviour intentional?

[zadjii-msft]

Huh. It looks like maybe this got undone by another change? I have been doing a LOT of bugfixes in this area as of late, so there's too much churn to effectively find where this regressed.

I'll reactivate a bug on this to get it in for 19H1. MSFT:19956461

[zadjii-msft]

Wait, I'm not totally sure we're doing it wrong. Here's a picture of xterm, with whatever it's default configuration is, compared to conhost with default attributes of 0xf0 (dark_black on bright_white):

Then here's two conhosts compared to Terminator. The top conhost (in the middle) has default attributes 0x07 (dark_white on dark_black). The bottom conhost has default attributes 0x0f (bright_white on dark_black).

The first conhost is "wrong", but I believe it's right considering it's settings.

And to get wild, here is conhost with a different foreground and background color selected, compared to the same colors in gnome-terminal:

I don't want to say that the virtual terminal is wrong but I'd be curious to see what settings it has, and why it appears different.

[j4james]

My test case was written with the assumption of "standard" default colors (7 foreground, 0 background). Using non-standard default colors just confuses the issue. A more robust test case would look like this:

printf "\033[0;1;40;37;7m ACTUAL \033[0;1;30;47m EXPECTED \033[m"

All I'm trying to determine is whether it's the foreground or the background color that is affected by the bold/bright attribute when the negative attribute is also set. My expectation was that the brightness would always apply to the foreground color. So white on black, negative, bold would be black on white, with the black foreground brightened, rather than the white background being brightened.

That said, I wouldn't want to claim that that is necessarily the correct interpretation. There clearly are some terminal emulators that apply the bright attribute to the background. I was initially only testing against the Linux virtual terminal and DOS, because I expected that was the behaviour you'd likely want to follow. And in both of those cases a bright background would never have been an option (the text mode of a typical PC video card couldn't support bright background colors, since the forth bit of the background attribute was used to trigger the flashing mode).

But if you're more interested in compatibility with xterm, then a bright background may well be the right choice for you. Although the actual xterm behaviour is stranger than that - the text becomes bold and the background becomes bright, which seems really odd to me.

TLDR: If the decision to make the background color bright was deliberate, then you're welcome to close this issue again. It's just not what I was expecting, and I though that you had initially agreed with me.

[zadjii-msft]

Sorry to necro this crazy old thread, but I'm just coming back around on this one.

Since it seems like there's not really a consensus on what the right behavior is, I'm going to say this is "by design". If as an ecosystem there's a more unified behavior here, then I'd be happy to re-open to do it right. But since there's not really a right behavior, I can't really fix it.

[egmontkob]

I've missed this bugreport so far – I'm going through all of @j4james's bugreports right now in the hope of catching some VTE bugs :D

Coincidentally, the same question occurred to me a couple of weeks ago, and I summarized my findings at https://bugzilla.gnome.org/show_bug.cgi?id=791596#c5.

IMO the only reasonable move is to push for leaving the "bold is bright" mess behind, and aim for full separation of font weight vs. colors (which I've already mentioned in one or two others issues here). Then we'll no longer have this dilemma.