ANSI colours aren't consistent across X terminal programs

March 7, 2023

There is a long standing set of 'ANSI colour codes' in terminal emulators, including terminal programs for X. Here is a table of them, and fidian/ansi will provide you with a convenient Bash script that will show you what these colors look like in your terminal program. The latter is potentially relevant because, shockingly, no two X terminal programs I've tried render these ANSI colours exactly the same (between xterm, urxvt, Gnome Terminal, and konsole; xfce4-terminal may render the same as Gnome Terminal in some quick tests).

I've traditionally been very against using colours in my terminals, because in my normal black on white choice, the colours programs chose often wind up looking like an angry fruit salad explosion. Given how glaringly annoying colours looked to me, I didn't really understand why other people liked them until, a few years ago, I noticed that the same colours in Gnome Terminal looked rather different and generally came across as less of an assault on my eyes. Using fidian/ansi and its --color-table option shows that I wasn't just imagining this; in side by side comparisons, Gnome Terminal seems to clearly shift colours (in a black on white setup) to less intense and more readable.

Beyond the colour shifts in Gnome Terminal, there are other interesting colour changes from what you might expect. For instance, in all terminal emulators, the result of rendering 'normal' white coloured text in a black on white terminal is not invisible white text, but a greyish colour that remains somewhat readable. There are also 'faint' versions of basic ANSI colours, and the interpretation of faint white text on a white background isn't necessarily what you'd expect and varies quite a bit between terminal programs (with urxvt seeming to ignore the faintness entirely for all colours).

With enough work I could probably find out what specific colours Gnome Terminal is using and adjust my xterm to use them, so I have less annoying colours on the rare occasions when I might need them. As a practical matter, I'm not that interested in having colours in my terminals; even most of Gnome Terminal's colours aren't all that appealing.

I'd like to put this forward as a reason for people to entirely avoid using colours in terminal programs and terminal environments, but I know that ship has sailed years ago. Apparently other people have found or set up colour sets in their terminals that they like and find a lot more readable than I do with any setup that I've seen.


Comments on this page:

The only use of color I tolerate in my terminal is grep --color which conveniently highlights the matches, especially when doing tail -f file | grep --color regexp...

From 193.219.181.242 at 2023-03-08 06:45:42:

I don't think the variation is a strong reason to avoid color usage; a +/- diff in green/red still looks like a diff in green/red regardless of the exact shades being used. Assuming it's still decently readable green/red, that is (some terminals stick to some variant of "historic VGA" colors where blue is nigh-invisible on a black background...)

While the 8/16-color palettes indeed differ a lot, the 256-color "6x6x6" ones are much more consistent (and usually not customizable) – and easier to find a non-eye-damaging color from. Increasingly more terminal emulators support full-on 8x8x8 RGB "direct color".

gnome-terminal has two main color schemes to choose from (ignoring the bad ones) – the new "GNOME" scheme starting with v40 or so:

XTerm*color0: #171421
XTerm*color1: #c01c28
XTerm*color2: #26a269
XTerm*color3: #a2734c
XTerm*color4: #12488b
XTerm*color5: #a347ba
XTerm*color6: #2aa1b3
XTerm*color7: #d0cfcc
XTerm*color8: #5e5c64
XTerm*color9: #f66151
XTerm*color10: #33d17a
XTerm*color11: #e9ad0c
XTerm*color12: #2a7bde
XTerm*color13: #c061cb
XTerm*color14: #33c7de
XTerm*color15: #ffffff
XTerm*boldColors: true
XTerm*boldMode: true

and the older "Tango" theme (GNOME 2.x brand colors) that was still the default in all 3.x versions:

XTerm*color0: #000000
XTerm*color1: #cc0000
XTerm*color2: #4e9a06
XTerm*color3: #c4a000
XTerm*color4: #3465a4
XTerm*color5: #75507b
XTerm*color6: #06989a
XTerm*color7: #d3d7cf
XTerm*color8: #555753
XTerm*color9: #ef2929
XTerm*color10: #8ae234
XTerm*color11: #fce94f
XTerm*color12: #729fcf
XTerm*color13: #ad7fa8
XTerm*color14: #34e2e2
XTerm*color15: #eeeeec
XTerm*boldColors: true
XTerm*boldMode: true

---

While browsing my configuration, I was reminded of something interesting about the two terminals (xterm and gnome-terminal) unrelated to colors. Sometimes I use a quite old 32-bit laptop for some casual linuxing, instead of the more modern machines, and I had a thought about switching it from gnome-terminal ot xterm for a more "traditional X11" experience… and it turned out that Xft-based fonts were so slow in xterm that it took whole seconds to render an 1024x768 screen. Whereas gnome-terminal was still as fast on the old Pentium (even with it being deliberately in 800 MHz "power-save" mode) as it was on the modern systems.

From 148.77.89.22 at 2023-03-08 10:45:08:

The color explosion problem is caused mainly by the use of the RGB color scheme being naively implemented by tech people who don't understand colors. The typical tech approach is to setup colors using the idea of "just max it out". So red is #FF0000, green is #00FF00, blue is #0000FF, where each color is just set to the max value for its component.

The thing is that human eye doesn't work this way and the max value #00FF00 of green is not perceived to be the same brightness as the max value of #0000FF blue. The CIELAB (and variants) color space has been painstakingly designed over many decades to ensure that colors have a visual similarity across the spectrum, as they are perceived by the human eye. It ensures that all colors have the same apparent brightness, etc.

If tech people spent some time actually thinking about these types of topics and setting software to use sane defaults, it would make the use of colors much more pleasant for everyone.

This is the intended behaviour of the basic colour control codes.

I'd like to put this forward as a reason for people to entirely avoid using colours in terminal programs and terminal environments, but I know that ship has sailed years ago.

Not all of us are stuck in the 1970s and believe minor additions that came later to be bad.

Apparently other people have found or set up colour sets in their terminals that they like and find a lot more readable than I do with any setup that I've seen.

It's easier to cope with ECMA-48 terminal control codes, despite how UNIX implementations break them or avoid features, than to cope with X11.

By Ian aka nobrowser at 2023-03-08 23:39:07:

On the other hand there is the solarized theme, which to me is so far washed out to be hardly readable. In any case, the idea of trying to have the same set of foregrounds work for both light and dark backgrounds seems to aim for suboptimality from the start.

Don't be too harsh on how terminal emulators render colors - physical ones are not that much better.

A lot can be blamed on the inconsistent implementations of RGBi signals in color TTL monitors in the 80's - while most manufacturers of CGA monitors tried to emulate IBM's scheme, even IBM couldn't make its 16 color palette consistent between CGA, EGA, VGA, and the mainframe/midrange (3270/5150, etc) terminals. This whole space is kind of a mess.

I myself customize my terminals to either a very dark unsaturated blue background with a roughly 70% intensity bluish-white or a 70% green on a 5% green background. Physical terminals, unfortunately, usually end up looking whatever the engineers (who really didn't think much about how we perceive colors) originally intended, plus natural aging of analog components.

Minor inconsistencies should be OK, anyway. I just hope most terminal writers pool their resources under projects such as VTE or QtTermWidget and incorporate those into their programs so there is at least one reference implementation going forward.

Written on 07 March 2023.
« Special tcpdump filtering options for OpenBSD's pflog interface
Debconf's questions, or really whiptail, doesn't always work in xterms »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Tue Mar 7 21:33:42 2023
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.