Good afternoon,
due to the ongoing discussion about color-handling in st I decided to
take a look at the code and figured out what the problem was.
What st basically does in xdraws() is to check if a given character is
bold. If that's the case, certain colour-intervals are brightened up
with offsets:
1) [0-7] -> offset 8 (normal system colors, full range)
2) [16-195] -> offset 36 (subset of the 256-color-range [16-231])
3) [232-251] -> offset 4 (subset of the grayscale-range [232-255])
The behaviour in 1) is sane and expected (check config.h);
2) and 3) however suffer from a number of issues:
a) The RGB-scale is non-linear[0].
----------------------------------
Eric Pruitt <eric.pruitt_AT_gmail.com> writes:
> If it were _just_ brighter, I probably wouldn't care, but to me, the
> difference in color is like night and day.
This is not surprising, giving a fixed offset on a non-linear
scale leads to color-shifts apart from the desired gamma-shift.
This mistake has been made often enough and shouldn't be made in a
suckless software.
Either make it right or leave it out (cf. Unix Philosophy).
b) Making bold text lighter doesn't make sense.
-----------------------------------------------
Looking at the colour-impression, bold text should rather be darkened,
as bigger areas of the same colour normally lead to a falsified lighter
impression.
Actually lighting it up even more makes color-shifts more obvious.
c) The offsets are applied to subsets of the full ranges.
---------------------------------------------------------
This is just an issue derived from how this was solved in a linear way.
You might want to say that it's trivial, as the lightest colours don't
need to be lit up, but just consider the gaps between 195,196 and
251,252.
d) Consistency
--------------
It's the client's job to set the 256-colour-representation. The
portage-utils for instance, employing 256-colours, make their own
adjustments to the colors of bold characters.
Forcing our invalid color-modification on the user just messes with
expected behaviour, and most importantly, with how the programs were
designed visually.
I wrote this patch to adress two things:
First, fix xdraws() to make it more consistent and work by a valid
colour-model (according to the points given above and Eric's patch).
Second, simplify the loops in xloadcols and other minor simplifications.
Cheers
FRIGN
[0]:
http://www.4p8.com/eric.brasseur/gamma.html
--
FRIGN <dev_AT_frign.de>
Received on Thu May 22 2014 - 15:03:21 CEST