Off-by-one in RGB truecolor escape sequence parameter indices

[egmontkob]

I know you weren't happy with adding ':' as separator, so probably you won't be happy about this one... I'm not happy about this either :-D

VTE's main developer Christian discovered that pretty much everyone misread/misimplemented the ITU Recommendation T.416 at truecolor escape sequences.

Pretty much all terminal emulators that implement true colors interpret the escape sequences the xterm-compatible way:

CSI 38;2;rrr;ggg;bbb m

taking exactly 3 parameters after "38;2;" (the rest, if any, are interpreted as brand new SGR codes).

Some even allow colon as the separator, and ideally also allow (and ignore) further optional parameters:

CSI 38:2:rrr:ggg:bbb[:unused:tolerance:color_space_for_tolerance] m

However, according to T.416 a.k.a. ISO 8613-6, this syntax is wrong. The correct format is (allowing colons only as separator):

CSI 38:2:[color_space_id]:rrr:ggg:bbb[:unused:tolerance:color_space_for_tolerance] m

Most apps that use truecolor emit the xterm-compatible escape sequences, because not too many terminal emulators support ':' as the delimiter, and understandably they choose the easy path which works everywhere. So I wouldn't touch the parameters of the semicolon-based sequence.

With the colon as separator, it would be nice to fix it and adhere to the standard. I'm a bit uncertain if keeping some level of backwards compatibility here (namely: if only three parameters follow the "38:2:" prefix then treat them as R, G, B) is a good idea or not.

Please see the VTE discussion for further details/thoughts.

I'm curious to hear your take on the story, and ideally key players of the story (i.e. popular terminal emulators) would agree on a direction to go.

[kovidgoyal]

Is there someplace this standard is publicly viewable, without needing to pay? Because I have zero sympathy for standards that are not freely available. And I have to ask, why do we care about this standard document anyway? No existing terminal emulators implement it. No applications use it. So why are we refering to it as canonical?

You might also want to involve @leonerd in this discussion.

[egmontkob]

Is there someplace this standard is publicly viewable, without needing to pay?

Google for it as "ISO 8613-6", they'll ask for a sh*tload of money. Google for it as "ITU Recommendation T.416" and the very same document is available for free.

And I have to ask, why do we care about this standard document anyway?

I believe the choice of "38;2;r;g;b" came from this document, I don't know about any other source mentioning anything similar. (Let me please know if you think this is not the case.) However, it was misinterpreted in two different ways, one is the usage of semicolons vs. colons, the other one is the omitted parameter.

I don't necessarily care about this particular standard, but I do care about something being interpreted and then implemented correctly, if at all.

No existing terminal emulators implement it. No applications use it. So why are we refering to it as canonical?

My earlier opinion why semicolon sucks and colon is okay from #160 still applies (and sure does yours, too).

[kovidgoyal]

On Tue, Dec 12, 2017 at 03:58:04AM -0800, egmontkob wrote: > Is there someplace this standard is publicly viewable, without needing to pay? Google for it as "ISO 8613-6", they'll ask for a sh*tload of money. Google for it as "ITU Recommendation T.416" and the very same document is available for free.

That's hilarious :) But thanks for the pointer.

> And I have to ask, why do we care about this standard document anyway? I believe the choice of "38;2;r;g;b" came from this document, I don't know about any other source mentioning anything similar. (Let me please know if you think this is not the case.) However, it was misinterpreted in two different ways, one is the usage of semicolons vs. colons, the other one is the omitted parameter. I don't necessarily care about this particular standard, but I do care about something being interpreted and then implemented correctly, if at all.

I dont know of any way to get into the mind of whoever first implemented this escape code to know what their inspiration for it was. I think the more important question to ask is: Does it make sense to change the implementation today? Pros: 1) Matches the standard Cons: 1) Breaks backward compatibility, unless you deviate from the standard anyway. In which case, why care about matching the standard? 2) Increases complexity throughout the ecosystem. 3) Means that setting colors now wastes an extra byte everywhere, all the time just to comply with a dead standard.

> No existing terminal emulators implement it. No applications use it. So why are we refering to it as canonical? My earlier opinion why semicolon sucks and colon is okay from #160 still applies (and sure does yours, too).

I totally agree about colons, I'm just questioning the utility of color space id. Do we really want to add a useless parameter that will be ignored by all terminal emulators but still need to be sent by every application.

[kovidgoyal]

Also looping @XVilka into this discussion

[leonerd]

I don't know of any terminal emulator or application that actually follows that additional parameter for the colour space. It may be that some terminal could apply some logic to count the number of arguments, indeed.

In practice for a sending application, it would be best just to stick to what is conventionally done by a number of terminals now - 38:2:r:g:b rather than including that colourspace as well.

On the subject of T.416, the fact it's not freely available does seriously limit the audience who can read it. At this point I'm trying to collect up what is commonly actually done in terminals, in order to obtain some sort of standard-by-consensus, rather than by reading some old piece of paper that nobody pays attention to these days anyway. My (very much work-in-progress) attempts can be found at

https://docs.google.com/spreadsheets/d/19W-lXWS9jYwqCK-LwgYo31GucPPxYVld_hVEcfpNpXg

[egmontkob]

1. Breaks backward compatibility [...]

Here the point is that it's practically not used by anyone (yet?). We can right now pretty safely make this change, it would hardly break anything.

[...] unless you deviate from the standard anyway. In which case, why care about matching the standard?

Luckily, if we insist on not breaking anything at all, this can still be done safely.

If we interpreted 3 additional parameters after "38:2:" as "R, G, B", and 4 or more parameters as "color-space-id, R, G, B, rest", then no valid escape sequences defined in the standard would be interpreted incorrectly. We'd just add some interpretation to something that's invalid according to the standard. And that's absolutely fine, and doesn't count as deviating from the standard any more than supporting semicolons.

2. Increases complexity throughout the ecosystem.

A tiny little bit. Way less than a mixture of good and bad interpretations does.

3. Means that setting colors now wastes an extra byte everywhere, all the time just to comply with a dead standard.

You don't have to store that color space anywhere. And I couldn't care less about the cost of those extra ":"s in the data stream while listening to music being streamed along with video that I'm not even looking at :D

[leonerd]

If we interpreted 3 additional parameters after "38:2:" as "R, G, B", and 4 or more parameters as "color-space-id, R, G, B, rest", then no valid escape sequences defined in the standard would be interpreted incorrectly. We'd just add some interpretation to something that's invalid according to the standard. And that's absolutely fine, and doesn't count as deviating from the standard any more than supporting semicolons.

Yes, I'd be happy with that as a compromise.

[kovidgoyal]

On Tue, Dec 12, 2017 at 12:31:04PM +0000, egmontkob wrote: > 1) Breaks backward compatibility [...] Here the point is that it's practically not used by anyone (yet?). We can right now pretty safely make this change, it would _hardly_ break anything.

You hope.

> [...] unless you deviate from the standard anyway. In which case, why care about matching the standard? Luckily, if we insist on not breaking anything at all, this can still be done safely. If we interpreted 3 additional parameters after "38:2:" as "R, G, B", and 4 or more parameters as "color-space-id, R, G, B, rest", then no _valid_ escape sequences defined in the standard would be interpreted incorrectly. We'd just add some interpretation to something that's _invalid_ according to the standard. And that's absolutely fine, and doesn't count as deviating from the standard any more than supporting semicolons.

Sure, I can live with that.

> 2) Increases complexity throughout the ecosystem. A tiny little bit. Way less than a mixture of good and bad interpretations does. > 3) Means that setting colors now wastes an extra byte everywhere, all the time just to comply with a dead standard. You don't have to store that color space anywhere. And I couldn't care less about the cost of those extra ":"s in the data stream while listening to music being streamed along with video that I'm not even looking at :D

Well, since I access remote systems using ssh over dubious network connections all the time, I very much care. But in the interests of harmony, I am perfectly willing to add support to kitty for ignoring the first parameter in a four parameter sequence. No software will ever send four parameters, so I guess the performance hit is not a real world concern. So, I will modify kitty to throw away the first parameter of a color sequence if there are four parameters.

[egmontkob]

You hope.

In VTE we have stable branches twice a year, and development (unstable) versions in between. We could temporarily disallow the lack of color-space-id, see if any reports come in, and revert for the stable branch. To have some more concrete feedback (or lack thereof) than a "hope".

So, I will modify kitty to throw away the first parameter of a color sequence if there are four parameters.

Thanks! :)