Comment by cb321
2 days ago
Interesting project. You might check out Arcan (https://arcan-fe.com/) if you've never heard of it. (EDIT: I see author recently added a link: https://github.com/tattoy-org/tattoy/blob/main/website/conte... )
A couple of points related to contrast ratio management:
- The Mynex answer here is very informative: https://stackoverflow.com/questions/596216/formula-to-determ...
- The "limit/bound" on the contrast ratio has a "polarity" (a +- sense). At least for "text", in almost every font there are many more background pixels than foreground pixels. So, for example, your human eyes can tolerate a lower text cell fg-bg contrast with a dark background color for the text cell on an all-black background than they can for a dark foreground color on an all-black background. Part of this relates to "shared discrimination work" that the outside-the-text cell background pixels are doing. So, really "ratio" of just two things is somewhat of an oversimplification.
- XTerm OSC 4 may have a very limited ability to probe the color palette. At least on `st` I can only see default foreground, background and cursor colors, not the full 16-color palette. This mostly just amplifies the point elsethread by @hnlmorg.
- At least until more recent ssh's, default configs on Linux would pass through all "LC_*" environment variables. So, if you adjust your shell rc/configs to key off of, say, $LC_THEME having, e.g., "light" or "dark" in them, you can perhaps re-polarize everything with a much lower tech solution. I do this all the time as I like to run some terminals with a black background and some with a white background. (Paper white black & white displays were all the rage in the 90s, but these days "color hackers" seem to prefer dark backgrounds. I have theories as to why, but it's pretty off topic.) https://github.com/c-blake/lc configs have more fully fleshed out examples, and hey, you might also like that color-ls. (And I'm aware of the ancient & to my mind ugly 1980s ideas of "stuff everything into $TERM and parse it apart again". Security concerns may push us back that way.)
Wow thanks for all this insight. I'd never considered the idea that the ratio of foreground to background pixels impacts the visual perception of text readability. Of course that totally makes sense now that I think about it. Do you know if that's been considered anywhere in the WCAG standards?
I'm thinking that I'm going to support both palette screenshotting and OSC 4.
I've certainly seen those LC_* variables before but I don't seem to have them right now in my current shell. Are you saying that they can be another source of the true colour values of the palette indexes?
AFAICT, this "number of pixels" (as well as the outside-the-cell pixels) effect is one of those "obvious as heck if you experiment on yourself with barely any science or even just contemplate it" things that somehow winds up ignored in standards. I'd love to be wrong, though.
The screenshotting is surely more portable.
I was not saying LC_* are a source of color values, though a terminal could surely do that as a way to export this data to its first shell without the clunky stdin/out protocols for OSC4. For example, I believe one variant of rxvt/urxvt used to export COLORFGBG. I would even say (LC_FG LC_BG LC_COLOR0..15 LC_CURSOR, etc) is an ok idea. One downside is a user could change the values since environment variables are very much not "read only", but that is sort of "on them" for fooling subprocesses "on purpose".
I was mostly lamenting that ssh server configs are moving toward making it hard(er) to "pass through" this kind of environment variable-driven setup. Something people often overlook in this general problem space is making whatever protocol they come up with also "work through to shells beyond one (or more) ssh hops". So, the LC_COLOR<N> idea would have been "more fabulous" 5..10 years ago when I would have anticipated "this will usually work". Maybe it could still be easier for some than OSC4.
Anyway, big topic with half century of history and hard to be brief.
> XTerm OSC 4 may have a very limited ability to probe the color palette. At least on `st` I can only see default foreground, background and cursor colors, not the full 16-color palette. This mostly just amplifies the point elsethread by @hnlmorg.
What st version? For me, 0.9.2 prints the entire color cube with
(although unsurprisingly, it's subtly broken: I sent ST, but the responses are terminated with BEL...)
You are completely right. It totally "works" now { scare quotes as per your termination comment.. ;-) . I guess xterm terminates in the answer back with whatever the client sends in the request. It's funny how now things began as DEC vtXX emulators and now things are "xterm emulators". }
Thank you for correcting the record, @shiomiru!