Anybody know of a patch for urxvt to support 24-bit color?

[clort81]

urxvt does not support 24 bit colors properly because it can't display more than a limited subset of colors at one time.

Is there any patch we could get into urxvt that would allow true (non paletted) 24 bit support?

It might be a big job (?). Certainly each colored string would need to remember the full 3 bytes of rgb color info, as opposed to one byte.

If each character in a 100 column, 10k line scrollback buffer got two bytes of color info added, that'd be another 2MB memory use.

If memory consumption is an issue. Color data could be a sparse array.

As a text artist, I find Urxvt completely fails with such images which display correctly in xterm, and other true 24bit terminals:

baroque-fantasy-city.ans.gz

[ghost]

have a look at this patch

[kurahaupo]

That patch is good but incomplete; it only implements the secondary compact format, and does not implement the original standard, namely CSI 38:5::Red:Green:Blue:Alpha m (where :Alpha is optional, and yes that's two colons before the Red component).

[SlySven]

Um, the "original standard" doesn't mention an Alpha component - it, being: https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-T.416-199303-I!!PDF-E&type=items {on page 49 of 77. labelled 41) actually says for parameter 6 of the CSI 38:2::Red:Green:Blue:XXX m sequence that "Parameter 6 has no meaning." (XXX here). Note that the CSI 38:4:... sequence is the only one where the 6th parameter IS used - for Black, where the prior ones are Cyan, Magenta, and Yellow in that order. FTR CSI 38:5:... only has ONE additional parameter, the colour index (0 to 255) for the 256 colour mode.

[kurahaupo]

@SlySven Fair point, the alpha part isn't actually defined by ISO/IEC-8613, but the interpretation of excess trailing components is insignificant compared with identifying which of the components are the primary colours.

The important part is that there should be "colour space identifier" before the colour components, even if it's empty with two consecutive colons.

That said, ISO/IEC-8613 states precisely that "parameter 6 has no meaning"; it is reasonable to interpret that as "has no meaning assigned by this standard", which in turn leaves it open for others to assign it a meaning, and in that context "alpha" is reasonable, especially when that's how the majority of extant 4-component RGBX encodings interpret the extra component.

If the standard had actually meant "does not have and never will have any meaning", it would have said something like "must be empty, and must be omitted if there are no following parameters"; or alternatively, "all implementations MUST ignore this parameter".

[SlySven]

Well, would it have any meaning to have an alpha component for a CMYK specified colour - that is when things get complicated given that there are two further (optional, and probably encountered about as often as the colour space identifier 🤣) components for all of the RGB, CMY and CMYK forms...

[kurahaupo]

Sure, CMYKA would need 5 components (7 in total, which means extending that limit), and its A would not line up with the A in RGBA. Whilst that would be "nice", it's not in any sense essential, since both RGBA and CMYKA would be extensions to the existing formal standard.

I suppose it could be argued that they should both have new initial codes, like CSI 38:12::R:G:B:A m and CSI 38:14::C:M:Y:K:A m, and maybe even CSI 38:15::Index:Alpha m.

But all of this is a digression. The real point is the empty 3rd parameter in CSI 38:n:HERE:...m.

[SlySven]

I suppose it could be argued that they should both have new initial codes, like CSI 38:12::R:G:B:A m and CSI 38:14::C:M:Y:K:A m, and maybe even CSI 38:15::Index:Alpha m.

TBH It would be less disruptive to use a single digit for the new "flavours" as that is less likely to break existing decoders - and there is space for them in the range 6 to 9 ... I could drop it into what I code for, Mudlet quite quickly...!

[kurahaupo]

@SlySven That's a really disturbing idea. I don't have a problem with using a single-digit code, but oh dear, are people really writing such insanely broken handlers that multiple digits would be a problem? I mean, how would you even start to code the thing such that there's a limit when sending a code?

Wouldn't you either have a static literal string like "\e[38;12;44;191;92;128m" or else a concatenation of arbitrary integer values like ["\e[", ([38,12,44,191,92,128].join(";")), "m"].join("") or else a string builder like sprintf("\e[%u;%u;%u;%u;%u;%um", 38,12,44,191,92,128)?

Are there other ways of writing this that could somehow break when given 12 instead of 5, and yet somehow not break when given an extra parameter?