RE: Turning off colorization

[Mirek Kaim <mirek.kaim@outlook.com>]

> From: yuri.v.khan@gmail.com
>
> You’re talking about 256 colors as if it were a whole lot.
>
> In fact, 256 is a very limited color space. It includes 16 base
> colors, a 6×6×6 color cube, and some 24 shades of gray. The color cube
> is typically configured with rather light colors, suitable for use as
> foreground on black (hex RGB value starting at 0x5f or something). As
> a consequence, there are very few dark non-gray colors in the
> 256-color palette.

it's what a lot of people have. there's nothing wrong with having support for true color terminals - if it's available, by all means, use it. some fallback for those with 256 colors should exist, though. writing some converter that maximizes contrast while preserving the hue as much as possible should be doable, but that's not my point.

my point is that current background and terminal/emacs theme shouldn't matter when rendering a website. terminal theme usually redefines base 16 colors, right? checking the background color suggests doing some fancy matching of the website palette to that background color, and possibly to all base 16 colors as well. kinda pointless, imho. current background should NOT be used. at all.

agreed, mapping rgb to 256 (-16) colors is far from being perfect either, but if that's the only (colorful) option available, there's no other way without touching the current terminal theme.

> Nowadays, nobody bothers about web-safe colors any more. We have the
> Tango palette, the Solarized palette, and a zillion other palettes,
> none mapping well to the xterm space.

it so happens that i am using solarized palette. 16 colors, defined as rgb values in mintty config. works pretty well and doesn't have to do anything with 256-color palette. one can change the base 16 colors on the fly using escape codes to any rgb values whatsoever on quite a few terminals, even those without full truecolor support, but that's changing the terminal theme altogether and the escape codes vary across terminals as well as across the environment (screen, tmux), so it's kinda useless here.

> Instead of coming up with clever heuristics about color remapping, we
> had better push for true color support in terminal emulators,
> libraries and applications.
>
> https://gist.github.com/XVilka/8346728

as i've said, fallback for 256-color terminals should be in place, imho. without remapping colors to the 256-color palette, probably the only sane option to preserve readability on such terminals would be to render the website in 24 shades of gray. far from perfect, but readable. i'm all for truecolor support in all terminal emulators, but we're simply not there yet.

on different note, for truecolor terminals/gui mode, it would be possible to get a nice 'easy on the eyes' website rendering for those that don't care about original website colors that much - and prefer solarized palette. for each rgb color, hue would be preserved, but saturation would change and luminosity would be mapped to solarized values depending if it's a background or foreground color, for constant contrast across the website. the mapping function would need to know if the rgb values describe foreground or background color, but that shouldn't be a problem for website renderer.

proper mapping of rgb values to 256-color palette shouldn't be that hard though, nor cpu intensive. the trick would be to map colors using foreground-background pairs to preserve contrast, even at the cost of changing one of the hues dramatically. it certainly wouldn't be as pretty as the truecolor original or - especially - truecolor solarized variant of the original, but it should remain readable when done right. which is, i guess, the main point of all this.

one more alternative i can think of is using 24 shades of gray together with shades of a single (selectable) color for 'accents'. the renderer would have to choose where to use those accents though (links/buttons/headers/whatever), but it would be easier to navigate than plain grayscale variant.


unic0rn