ITU/ODA colors with a zero color space don't work

[j4james]

Windows Terminal version

1.24.2812.0

Windows build number

10.0.19045.5371

Other Software

No response

Steps to reproduce

Open a WSL shell and execute the following statements:

printf "\e[38:2::255:0:0mRED\e[m\n"
printf "\e[38:2:0:255:0:0mRED\e[m\n"

These are ITU T.416 RGB color sequences that set the foreground to bright red. The first case is using a default color space ID, and the second case has the color space ID set to zero, which should be the same thing.

Expected Behavior

In both cases I'd expect the text to be rendered with a red foreground color.

Actual Behavior

Only the first case is red - the second case is rendered with the default attributes.

Looking at the code, it seems this was somewhat by design. We're trying to detect cases where the sequence is incorrectly formatted, with the red component in the position of the color space ID. And the assumption is that it's better to ignore those sequences than produce a completely wrong color.

terminal/src/terminal/adapter/adaptDispatchGraphics.cpp

Lines 128 to 131 in 4701844

	// We treat a color as invalid if it has a non-empty color space ID, as
	// some applications that support non-standard ODA color sequence might
	// send the red value in its place.
	const bool hasColorSpaceId = options.at(1).has_value();

But if we're going to take that approach, I think the test probably needs to be stricter, because this is clearly not an incorrectly formatted colour - it has all the required components. And most other terminals that support ITU colors do render this case correctly (although we're not the only one that fails).

So maybe we should only be rejecting sequences that have a non-default color space, but also have a missing blue component?

[DHowett]

So maybe we should only be rejecting sequences that have a non-default color space, but also have a missing blue component?

That makes a lot of sense to me. Good catch, btw!