emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Turning off colorization


From: Mirek Kaim
Subject: RE: Turning off colorization
Date: Tue, 11 Nov 2014 18:58:56 +0100

> From: address@hidden
>
> 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
                                          


reply via email to

[Prev in Thread] Current Thread [Next in Thread]