I agree. I always customize the blue color on my terminal because dark blue on black is completely unreadable to me (and I'm not even color blind!). For some reason, every single terminal emulator defaults to a blue that's unreadable on a black background (I think typically #00f).
If a tool overrides my color settings, it too usually picks a dark blue that's unreadable on my black background.
Most of them are emulating the EGA/VGA palette which was a regression from the CGA terminal colors.
https://int10h.org/blog/2022/06/ibm-5153-color-true-cga-pale...
Not really, because the dark yellow (not brown) is used... it's similar, but not the same in most terminals... brown as dark yellow for cga was a kind of short to a different color mix than the natural position which most terminals now use... actual screen effectiveness/brightness is different as well.
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.
https://github.com/bbs-land/webterm-dos-ansi
I have no idea if this was the reason behind turning the dark yellow into brown, but the brown was a much better looking color for DOS games so it was a good call
They could also have done something about the two magentas though... E.g. made one of them orange?
The light red usually appeared somewhat orangy/peachy, it's generally used as flesh for ansi artworks.
ex: https://16colo.rs/pack/ice-200207a/ti-war.ice
I think it was just determined that brown would be more useful than the darker yellow in practice. Other xterm colors are also a bit off from CGA/EGA/VGA DOS colors.
Is there a human that can read that dark blue on black or is it just us who has their eyes wired differently?
I have to select that text to change the background to read it.
No one can and people have been complaining about it for decades.
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.
If I was the maintainer of a terminal emulator, I would see a quite obvious way to improve the situation for my users: change the default colors so that dark blue is brighter.
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.
Because it means making choices, breaking assumptions, etc.. They have made it user-customizable so they don't have to go through all that.
FWIW, the current de-facto standard is set by xterm. Here is a relevant excerpt of its source code:
Make that what you will :-).Running a software project means making choices. Currently, the choice is made to make blue text unreadable. That's not a great choice, in my opinion.
> the current de-facto standard is set by xterm.
That’s true for 256 colour and various other escape codes too. But I wouldn’t say it’s true for 16 colour pallet.
Quite a few terminal emulators do this already. Including the one I maintain.
There are fewer blue cones in the fovea centralis than there are in the surrounding parts of the macula, so humans can't resolve details as well in blue light.
Which is why people who understand color tend to add a bit of green in to make a color which still looks deep blue but is much brighter than what #00f looks like
And I filed a PR because an author used yellow and hadn’t assigned orange to any purpose, which is actually legible on a white terminal where yellow never is.
Not just me then? My "dark blue" is always a kind of pale washed-out-bluey-grey because of that.