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/