[konsole] [Bug 387914] New: Add support for ':' as separator for extended color codes; watch out for index off-by-one

[Egmont Koblinger]

https://bugs.kde.org/show_bug.cgi?id=387914

            Bug ID: 387914
           Summary: Add support for ':' as separator for extended color
                    codes; watch out for index off-by-one
           Product: konsole
           Version: unspecified
          Platform: Other
                OS: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: NOR
         Component: emulation
          Assignee: konsole-devel at kde.org
          Reporter: egmont at gmail.com
  Target Milestone: ---

256-color support was added a long time ago in bug 107487. Even there it was
noted that the separator should have been ':' instead of ';' according to the
standard, yet this never got fixed.

Not sure if truecolor was added in that patch or at a later step, but it was at
least mentioned there and then added at some point.

VTE developer Christian has just discovered that not only the separator
character, but also the parameters of truecolor was misread and implemented
incorrectly by pretty much all terminal emulators (probably due to copying each
other).

According to ITU Recommendation T.416, the correct separator (for 256-color and
truecolor subparameters) is the colon (and not semicolon), plus the parameters
for truecolor go like:

  CSI 38:2:[color_space_id]:R:G:B[:unused:tolerance:color_space_for_tolerance]m

That is, at truecolor, there's an extra parameter at the beginning before the
three color components, plus optional parameters at the end. For example, to
get red=255, green=128, blue=64 (an orange-ish color), the sequence could be

  CSI 38:2::255:128:64m

Most apps that support truecolor emit sequences like CSI 38;2;R;G;Bm, because
not too many terminal emulators support ':' as the delimiter (konsole doesn't
either), and understandably app developers take the easy path which works
everywhere. So I wouldn't touch the parameters of the semicolon-based sequence,
it'd break existing truecolor support at many places, and there's no way to
inject that missing parameter without breaking compatibility with existing
implementations. I think we should say this format has become the de facto
standard.

It would be nice though to implement the de jure standard, too. That is, allow
colons as separators, and with colons used for truecolor mode watch out that
there's another parameter before the red channel, plus optional ones after
blue.

For backwards compatibility with the colon-based format with the color_space_id
omitted, you _may_ want to still accept only 3 additional parameters after
"38:2:" and treat them as R, G and B. But as soon as 4 or more parameters
follow "38:2:", the first one should be the color_space_id, then the three
color channels, then perhaps further additional ones. Given that konsole
doesn't support colons yet, I don't see too much point in implementing another
misinterpretation of the standard though.

The end of the optional parameters is obviously denoted either by the trailing
'm', or the semicolon ';' which allows further independent SGR attributes to
follow.

See https://gist.github.com/XVilka/8346728#gistcomment-2008553 for my opinion
about why colon (as stated by the documentation) is a good choice for
subparameters and semicolon (in widespread use) is a bad one.

For more details about the whole story, please see 

https://bugzilla.gnome.org/show_bug.cgi?id=791456

https://gist.github.com/XVilka/8346728#gistcomment-2285644

-- 
You are receiving this mail because:
You are the assignee for the bug.