azorius.net

Terminal colours are tricky (jvns.ca)
from kirk781@discuss.tchncs.de to technology@lemmy.world on 18 Jan 2025 14:17
https://discuss.tchncs.de/post/28801523

#technology

threaded - newest

tal@lemmy.today on 18 Jan 2025 15:04 collapse

Not to mention that the article author apparently likes dark-on-light coloration (“light mode”), whereas I like light-on-dark (“dark mode”).

Traditionally, most computers were light-on-dark. I think it was the Mac that really shifted things to dark-on-light:

My understanding from past reading was that that change was made because of the observation that at the time, people were generally working with computer representations of paper documents. For ink economy reasons, paper documents were normally dark-on-light. Ink costs something, so normally you’d rather put ink on 5% of the page rather than 95% of the page. If you had a computer showing a light-on-dark image of a document that would be subsequently printed and be dark-on-light on paper, that’d really break the WYSIWYG paradigm emerging at the time. So word processors and the like drove that decision to move to dark-on-light:

Prior to that, a word processor might have looked something like this (WordPerfect for DOS):

Technically, I suppose it wasn’t the Mac where that “dark-on-light-following-paper” convention originated, just where it was popularized. The Apple IIgs had some kind of optional graphical environment that looked like a proto-Mac environment, though I rarely saw it used:

Update: apparently that wasn’t actually released until after the Mac. This says that that graphical desktop was released in 1985, while the original 128K Mac came out in 1984. So it’s really a dead-end side branch offshoot, rather than a predecessor.

The Mac derived from the Lisa at Apple (which never became very widespread):

And that derived from the Xerox Alto:

But for practical purposes, I think that it’s reasonably fair to say that the Mac was really what spread dark-on-light. Then Windows picked up the convention, and it was really firmly entrenched:

Prior to that, MS-DOS was normally light-on-dark (with the basic command line environment being white-on-black, though with some apps following a convention of light on blue):

Apple ProDOS, widely used on Apple computers prior to the Mac, was light-on-dark:

The same was true of other early text-based PC environments, like the Commodore 64:

Or the TRS-80:

When I used VAX/VMS, it was normally off a VT terminal that would have been light-on-dark, normally green, amber, or white on black, depending upon the terminal:

And as far as I can recall, terminals for Unix were light-on-dark.

If you go all the way back before video terminals to teleprinters, those were putting their output directly on paper, so the ink issue comes up again, and they were dark-on-light:

But I think that there’s a pretty good argument that, absent ink economy constraints, the historical preference has been to use lig

orclev@lemmy.world on 18 Jan 2025 16:39 next collapse

It should be pointed out that modern LCDs use local dimming zones to only light up certain parts of the display, although that only really helps if large swaths of the image are solid black. LCDs have come a long way from the old days when they were side or backlit by CCFLs. So even LCDs might draw slightly less power for light-on-dark, although you’d probably get even more benefit by just turning down the displays brightness regardless of the color scheme.

arandomthought@sh.itjust.works on 18 Jan 2025 19:35 next collapse

Wow that was quite an encyclopedic post. Thank you for the good read!

QuarterSwede@lemmy.world on 19 Jan 2025 03:17 next collapse

Superb comment. Well done! Very enjoyable to read and posit about.

MonkderVierte@lemmy.ml on 26 Jan 2025 11:18 collapse

It was due to neccesity too that light on dark was used in CLI environments, due to the way CRT work, not because it’s superior or whatever. It could even be argued that the blue background of some tools was the equivalent of a light mode.

tal@lemmy.today on 26 Jan 2025 15:42 collapse

It was due to neccesity too that light on dark was used in CLI environments, due to the way CRT work, not because it’s superior or whatever.

No, you can run dark-on-light material on CRTs just fine. Literally all of the screenshots I have in the above post with dark-on-light are of computer systems that were sold with CRTs. The transition to LCDs didn’t come until something like twenty years after the transition from light-on-dark.

MonkderVierte@lemmy.ml on 26 Jan 2025 21:32 collapse

I thought more of earlier models and then usus. Ok, maybe not 100% neccessity.

Btw, does tty have a background-/color option?

tal@lemmy.today on 26 Jan 2025 23:02 collapse

I’m not sure what you mean by “tty”.

Televisions or computer displays? They didn’t (well, normally, probably some television out there that can do it) – if you plug an Apple II into a television or a display, it’s just gonna be light-on-dark.

Hardware dumb terminals, like VT100s? I’ve never seen one configured that way, but it might be possible that some supported running in light-on-dark mode. There are escape codes that will throw the terminal into showing reverse mode, and that was used for stuff like highlighting text, but I don’t know if there was an option invisible to the remote end to reverse colors. Like, you could set some of the default terminal modes at boot, stuff like terminal speed and such, but I don’t know if there’s a persistent flag that would always override what the remote end was using.

kagis

vt100.net/docs/vt510-rm/DECSCNM.html

Screen Mode: Light or Dark Screen

This control function selects a dark or light background on the screen.

Default: Dark background.

vt100.net/docs/vt100-ug/chapter3.html

Screen:

Changeable from Host Computer? Yes (DECSCNM)

Saved in NVR and Changeable in SET-UP: Yes

So on the VT100, there was a flag you could set that would be saved in nonvolatile memory that would persist across terminal boots, but it also could be flipped by the remote end, wasn’t invisible to it. If you used escape sequences that fiddled with the color mode, I’m not sure if it’d retain that.

Virtual terminal programs? xterm has -rv/+rv, which flips the foreground/background color, and pretty much all virtual terminal programs have some way to configure the 8/16 ANSI colors they use. If you’re talking changing how they interpret 8-bit color codes or 24-bit color codes, I don’t believe that I’ve typically seen some sort of mapping system in virtual terminal software – like, normally one configures software emitting those color codes on a per-program basis; normally, software that uses one of those will also have configurable color options. Like, Cataclysm: Dark Days Ahead, which uses IIRC 8-bit color, has a default set of colors, a set of alternate themes, and can be configured on a per-color basis. Ditto for emacs. Most console software uses the ANSI colormap, so remapping that in virtual terminal software handles most cases. Use of either 8-bit or 24-bit color by console software is fairly rare, so that’s tolerable today, though I imagine that if use becomes really common, that maybe virtual terminal software will try to add some sort of high-level mapping of colors.

MonkderVierte@lemmy.ml on 27 Jan 2025 09:45 collapse

My bad, i meant getty, the initial terminal service.