[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[screen-devel] [bug #52667] Off-by-one in RGB truecolor escape sequence
From: |
Egmont Koblinger |
Subject: |
[screen-devel] [bug #52667] Off-by-one in RGB truecolor escape sequence parameter indices |
Date: |
Thu, 14 Dec 2017 15:45:07 -0500 (EST) |
User-agent: |
Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:56.0) Gecko/20100101 Firefox/56.0 |
URL:
<http://savannah.gnu.org/bugs/?52667>
Summary: Off-by-one in RGB truecolor escape sequence
parameter indices
Project: GNU Screen
Submitted by: egmont
Submitted on: Thu 14 Dec 2017 08:45:06 PM UTC
Category: Program Logic
Severity: 3 - Normal
Priority: 5 - Normal
Status: None
Privacy: Public
Assigned to: None
Open/Closed: Open
Discussion Lock: Any
Release: Cur Dev Sources
Fixed Release: None
Planned Release: None
Work Required: None
_______________________________________________________
Details:
screen accepts 256-color escape sequences like CSI 38;5;INDEXm and truecolor
ones like CSI 38;2;R;G;Bm (also with colon as delimiter instead of semicolon).
(And similarly 48 for background.)
In fact, screen seems to treat colon and semicolon identically everywhere,
e.g. CSI 4:3m switches to underlined(4) and italic(3), just as CSI 4;3m does.
GNOME Terminal developer Christian has recently discovered that pretty much
everyone (including xterm, VTE (gnome-terminal), screen etc.)
misread/misimplemented the ITU Recommendation T.416 at truecolor escape
sequences (and/or copied the false interpretation from each other).
Carefully reading the spec (which only allows ':' as the separator) the actual
format is:
CSI 38:5:INDEXm
and
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, 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 (faulty)
implementations. I think we should say this format has become the de facto
standard.
With the colon as separator, however, it would be nice to fix it and adhere to
the de jure standard. That is, take another parameter before the red channel,
plus allow optional ones after blue.
For backwards compatibility with the colon-based format and 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.
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; and why terminal
emulators (such as screen) shouldn't treat them equally.
For more details about this particular issue, please see
https://bugzilla.gnome.org/show_bug.cgi?id=791456
https://gist.github.com/XVilka/8346728#gistcomment-2285644
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?52667>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
- [screen-devel] [bug #52667] Off-by-one in RGB truecolor escape sequence parameter indices,
Egmont Koblinger <=