On Monday, 26 May 2025 03:39:35 BST G. Branden Robinson wrote:
> 2. Deri submitted an interesting patch to grotty, implementing "true
> color" support.[3] I think it uses Thomas Dickey's xterm extension
> for 24-bit direct color support (terminology is all over the place
> in this area, and the patch suggests a familiarity mainly with the
> S-Lang view of the terminal color model, which I think is
> blinkered[4]).
>
> I'd like to merge the patch, but I'll likely whack on it a bit
> afterwards.
>
> In the meantime, it would be helpful to me, and possibly fun for
> groff users, if people tried applying the patch and exercising the
> new feature to see how it sits, and reported their findings here
> or to the Savannah ticket.[3]
>
> See y'all soon!
Hi Branden,
Have a nice holibobs.
Attached is a little test script which shows a graduated rainbow on one tty
line. I have a couple of queries.
A) Should tty.tmac now include all the named colours in ps.tmac since it can
show them all on the screen?
B) Currently I have implemented a -t flag for grotty to "turn on" 24 bit
colour support, rather than the legacy 4 bit colours, however, this is not
strictly necessary. If grotty starts up legacy mode it could switch to RGB
mode the first time the document it is processing uses a colour which is not
one of the 8 legacy colours. This would mean that any existing documents which
just used the legacy colours would render the same, but any new documents
which used RGB colours would automatically switch to the new mode.
There is a little wrinkle in the ointment (which is why I implemented a
separate flag to use 24 bit colours). Tty.tmac currently defines "yellow" as
rgb #ffff00 which is correct in rgb terms, but if you use \m[yellow] the text
or equivalent background is actually a brown, because there are only 8 colours
in 4 bit mode, the other 8 colours are "bright" versions of the 8 colours, and
grotty reserves the bright versions for the bold font, which means you only
get the true yellow using the bold font, which in turn means there is no
legacy way of getting the true "bright" yellow background. In 24 bit mode no
behind the scenes fiddling to the colour is done, you get exactly the colour
requested, if you use the bold font the glyph is emboldened but the colour
remains what was requested. This applies to all 8 legacy colours, even "black"
has a "bright" version! This means that in a new document if you used
\m[steelblue] before \m[yellow] you would get the proper yellow because it has
switched to RGB mode when producing the blue but if the order of the colours
is reversed then the yellow would be the legacy brown since grotty has not
switched to RGB mode until the steelblue is encountered. This is why I
introduced a new flag rather than deduce the desired mode algorithmically, but
people may prefer the convenience of the detection method not withstanding the
"wrinkle".
One advantage of using RGB mode text colours is that they will appear the same
on ps/pdf output.
Cheers
Deri
.\" Rainbow.trf
.\"
.\" Implementing this awk script in groff:-
.\"
.\" awk 'BEGIN{
.\" s="/\\/\\/\\/\\/\\"; s=s s s s s s s s;
.\" for (colnum = 0; colnum<77; colnum++) {
.\" r = 255-(colnum*255/76);
.\" g = (colnum*510/76);
.\" b = (colnum*255/76);
.\" if (g>255) g = 510-g;
.\" printf "\033[48;2;%d;%d;%dm", r,g,b;
.\" printf "\033[38;2;%d;%d;%dm", 255-r,255-g,255-b;
.\" printf "%s\033[0m", substr(s,colnum+1,1);
.\" }
.\" printf "\n";
.\" }'
.\"
.\" Found at:-
.\"
.\" https://github.com/termstandard/colors?tab=readme-ov-file
.\"
.\" Run: ./test-groff -Tutf8 -P-t Rainbow.trf
.\"
.pl 10v
.ll 78n
.de cell
. nr r 255-((\\$1*255)/76)
. nr g (\\$1*510)/76
. nr b (\\$1*255)/76
. if \\n[g]>255 .nr g 510-\\n[g]
. nr fr 255-\\n[r]
. nr fg 255-\\n[g]
. nr fb 255-\\n[b]
. defcolor BG rgb \\n[r]u*256u+\\n[r]u \\n[g]u*256u+\\n[g]u \\n[b]u*256u+\\n[b]u
. defcolor FG rgb \\n[fr]u*256u+\\n[fr]u \\n[fg]u*256u+\\n[fg]u \\n[fb]u*256u+\\n[fb]u
. ds t /
. if \\$1%2 .ds t \[rs]
. nop \M[BG]\m[FG]\\*[t]\m[]\M[]\c
..
.nr col 0
.while \n[col]<77 \{\
. cell \n[col]
. nr col +1
\}\
