[screen-devel] [bug #52667] Off-by-one in RGB truecolor escape sequence parameter indices

[Egmont Koblinger]

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/