Small Shift in Color Values
nihilhill at gmail.com
Tue Nov 29 14:34:20 CET 2011
Marc Lehmann a écrit :
> On Sun, Nov 27, 2011 at 02:33:56PM +0100, Bastien Dejean <nihilhill at gmail.com> wrote:
> > > > URxvt.foreground: #9E9E9E
> > >
> > > Your hardware is likely only capable of displaying colours #9d9d9d9d9d9d
> > > and #9e9e9e9e9e9e - urxvt picks the nearest colour to the one you specify
> > > (#9e009e009e00).
> > If I issue:
> > printf '\033[38;5;247m%b\033[0m\n' '█'
> > The color of the corresponding block is seen as '#9E9E9E' by gpick.
> Boy that must be some broken program - or maybe gpick samples an area
> or something and you are not aware of that? Doesn't seem to be the case
No, I set *oversample* to 0.
I've looked at grabc (no other dependencies except X), the relevant
(bogus?) piece of code seems to be:
r=(color.red >> 8);
g=(color.green >> 8);
b=(color.blue >> 8);
Where `color` is the *real* hardware color.
> In any case, I just installed gpick 0.2.4-1, and when using the picker
I use the latest mercurial version.
> thing in the lower right, I get "#9c9c9c" for both normal text and the
> block your command prints.
It should be '#9E9E9E'.
I tried the following:
xmag sees it as (fefe, fefe, fefe).
More information about the rxvt-unicode