[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
- Re: Turning off colorization, (continued)
- Re: Turning off colorization, Richard Stallman, 2014/11/08
- Re: Turning off colorization, James Cloos, 2014/11/08
- Re: Turning off colorization, Lars Magne Ingebrigtsen, 2014/11/08
- Re: Turning off colorization, James Cloos, 2014/11/08
- Re: Turning off colorization, Lars Magne Ingebrigtsen, 2014/11/08
- Re: Turning off colorization, Eli Zaretskii, 2014/11/08
- RE: Turning off colorization, Mirek Kaim, 2014/11/10
- Re: Turning off colorization, Eli Zaretskii, 2014/11/10
- RE: Turning off colorization, Mirek Kaim, 2014/11/10
- Re: Turning off colorization, Yuri Khan, 2014/11/10
- RE: Turning off colorization,
Mirek Kaim <=
- Re: Turning off colorization, Eli Zaretskii, 2014/11/08
- Re: Turning off colorization, James Cloos, 2014/11/09
- Re: Turning off colorization, Eli Zaretskii, 2014/11/09
- Re: Turning off colorization, Richard Stallman, 2014/11/09
- Re: Turning off colorization, Eli Zaretskii, 2014/11/09
- Re: Turning off colorization, Richard Stallman, 2014/11/10
- Re: Turning off colorization, Eli Zaretskii, 2014/11/10
Re: Turning off colorization, Paul W. Rankin, 2014/11/09