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-de...@kde.org
Reporter: egm...@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 watching all bug changes.
