If a tool overrides my color settings, it too usually picks a dark blue that's unreadable on my black background.
https://int10h.org/blog/2022/06/ibm-5153-color-true-cga-pale...
Kind of anal about this since I started with a lot of CGA and EGA displays when I was in my late teens and early 20s and relatively involved in the ANSi art scene.
Here's a related project I'm working on for playing doors in a web browser.
They could also have done something about the two magentas though... E.g. made one of them orange?
I have to select that text to change the background to read it.
But there is no standard or standard body anywhere for terminal colors so there is no obvious way to improve this situation.
And no urgency either, because all terminal emulators allow users to customize the palette anyway.
There's no obvious way to unilaterally improve the situation across the whole ecosystem, that's true. But I don't understand why individual terminal emulator maintainers don't fix it for their users.
FWIW, the current de-facto standard is set by xterm. Here is a relevant excerpt of its source code:
! Disclaimer: there are no standard colors used in terminal emulation.
!
! The choice for color4 and color12 is a tradeoff between contrast, depending
! on whether they are used for text or backgrounds. Note that either color4 or
! color12 would be used for text, while only color4 would be used for a
! background. These are treated specially, since the luminosity of blue is
! only about half that of red/green, and is typically not accounted for in the
! RGB scheme.
!
! Blue text on a black background should be readable.
! Blue backgrounds should not be "too" bright.
!
! Originally color4/color12 were set to the names blue3/blue
!*VT100*color4: blue3
!*VT100*color12: blue
!
! They are from rgb.txt respectively:
! 0 0 205 blue3
! 0 0 255 blue
! However, blue3 is not readable on a black background.
!
! Another choice was from the Debian settings:
!*VT100*color4: DodgerBlue1
!*VT100*color12: SteelBlue1
!
! From rgb.txt:
! 30 144 255 DodgerBlue1
! 99 184 255 SteelBlue1
!
! Some users object to this choice because the background (color4) is brighter
! than they are accustomed. Others point out that the different weights for
! the red/green components make it appear to be not really blue. Finally, it
! provides poor contrast against color13 and color14.
!
! The current choice uses equal weights for red/green (effectively adding a
! gray to the result). It is brighter than the original choice, and provides
! more contrast between color12 and color13, color14 than SteelBlue1 did.
! Contrast of color4 against black is slightly improved over the original.
!
! Some refinement is certainly possible (you are welcome to try) -TD
That’s true for 256 colour and various other escape codes too. But I wouldn’t say it’s true for 16 colour pallet.
An even bigger one is hardcoding black and white instead of using foreground/background and use reverse when needed.
Similarly, the user can also set their own fonts for the terminal, just as you can with colours and other functions. (However, some programs will have a reason to configure the fonts and palettes for the specific use, although most won't and even if they do the user might disable those features.)
A program can have an option (possibly by environment variable) to disable colours entirely; this might be necessary even if you can disable colours in the terminal emulator, because a program might want to use such things as reverse video, underlined text, etc to indicate some things when colours are disabled. (Disabled colours can also be useful if you do not have a colour display or if you want to print out a screenshot without a colour printer.)
But I wonder what the developers of gdb were using that made them not notice this
now that react devs finished destroying the web they have to impose their superior taste into terminal through 800mbs TUIs.