Support more OSC color formats

[egmontkob]

I was surprised when j4james told me in another bug that WT supports OSC 4/10/11 because that wasn't what I experienced. And just when I was about to respond to him, I realized:

WT supports OSC 4/10/11, but only with a very limited syntax for the values.

xterm's ctlseqs refers to the XParseColor manual page for supported syntax – IMHO an unfortunate choice for an OS-independent protocol to refer to an OS-specific library method, nevermind.

So the supported formats, in xterm, are at least these nine:

• rgb:R/G/B
• rgb:RR/GG/BB
• rgb:RRR/GGG/BBB
• rgb:RRRR/GGGG/BBBB
• #RGB
• #RRGGBB
• #RRRGGGBBB
• #RRRRGGGGBBBB
• hundreds of English names, like orange, lightblue2 etc.

WT only supports the second one of these.

The first syntax is recognized, but R/G/B is interpreted as shorthand for 0R/0G/0B instead of RR/GG/BB, thus always resulting in a pretty much black color.

I especially expected the fourth format, rgb:RRRR/GGGG/BBBB to be supported, because this is the one in which these OSCs respond in xterm and VTE, if the color is replaced by a ?. (This isn't supported by WT either, but that's for another bug.)

Note 1: The XParseColor documentation says the # formats are discouraged. I would, however, encourage their use as this is the standard notation on the web and other places too. Also, presumably plenty of forum posts (e.g. on the Stack Exchange suite) already provide answers using these.

Note 2: The XParseColor documentation says that #RGB is equivalent to #R000G000B000, and xterm implement this. In VTE it is equivalent to #RRGGBB a.k.a. #RRRRGGGGBBBB instead, as on the web. This is only for the # notation, for the rgb: notation the doc says and both of these impementations go with RR/GG/BB a.k.a. RRRR/GGGG/BBBB.

Note 3: The 12-bit variants RRRGGGBBB repeat the first digit at the end, e.g. #123456789 becomes #123145647897, and same for the rgb: notation. This probably doesn't really matter since at the end it's probably chopped to 8 bits per channel anyway.

Note 4: If Windows provides any library that converts popular English names to colors, I think it would be great to use that, IMO it doesn't matter if the exact supported names and their exact values aren't the same as on Linux. If not, you might want to copy an equivalent of rgb.txt to your source; hopefully there are no licence constraints preventing this.

Note 5: As per the linked manual, xterm also supports rgbi:rfloat/gfloat/bfloat whereas the mapping from the 0.0 .. 1.0 float range to 0x00 .. 0xFF is not linear; and sure those CIELab and friends as well. These are not supported by VTE.

[zadjii-msft]

Yea you're definitely right - we should support these too :)

[j4james]

Yeah sorry, I should have been clearer about the limits. There was actually a follow up issue raised for this at the time the original OSC code was implemented (see #942). So I think this is essentially a dup of that, although it doesn't have as much info as you've got here. If this is closed as a dup, it would be good to copy those details across.

[zadjii-msft]

I'm setting #942 as the megathread to track all these requests, including the other new ones @egmontkob filed. They were all tracked as bullets on that issue before, but they should frankly each be individual tasks.

[egmontkob]

My bad, I saw #942 but then only read its title "support for multi-param OSC" and it looked different.

@zadjii-msft Please copy-paste over my bits and close this as dup, or leave it here, whichever you prefer.

[DHowett-MSFT]

I'll leave this one here as an "attached" issue. 😄 Thanks @egmontkob

[ghost]

🎉This issue was addressed in #7578, which has now been successfully released as Windows Terminal Preview v1.5.3142.0.:tada:

Handy links:

• Release Notes
• Store Download