Re: [hackers] [st][PATCH] Fix truecolor being slightly inaccurate

From: Mikau <mikau_AT_aaathats3as.com>
Date: Mon, 7 Mar 2022 15:23:50 +0100

On Sun, 6 Mar 2022 21:07:41 +0800
Yutao Yuan <yyt16384_AT_gmail.com> wrote:

> The displayed color in truecolor mode is sometimes darker than
> requested. The inaccuracy can be verified with the following example,
> which should paint a white block but instead produces color #fefefe.
>
> printf '\e[38;2;255;255;255m\u2588\u2588\u2588\n'

I'm also getting #FEFEFE. The only thing I have found that might
explain this discrepancy is this section from XParseColor(3):
> An RGB Device specification is identified by the prefix “rgb:”
> and conforms to the following syntax:
>
> rgb:<red>/<green>/<blue>
>
> <red>, <green>, <blue> := h | hh | hhh | hhhh
> h := single hexadecimal digits (case insignificant)
>
> Note that h indicates the value scaled in 4 bits, hh the
> value scaled in 8 bits, hhh the value scaled in 12 bits, and hhhh the
> value scaled in 16 bits, respectively.
>
> For backward compatibility, an older syntax for RGB Device is
> supported, but its continued use is not encouraged. The syntax is
> an initial sharp sign character followed by a numeric
> specification, in one of the following formats:
>
> #RGB (4 bits each)
> #RRGGBB (8 bits each)
> #RRRGGGBBB (12 bits each)
> #RRRRGGGGBBBB (16 bits each)
>
> The R, G, and B represent single hexadecimal digits. When
> fewer than 16 bits each are specified, they represent the most
> significant bits of the value (unlike the “rgb:” syntax, in which
> values are scaled). For example, the string “#3a7” is the same as
> “#3000a0007000”.
Maybe different implementations of one of the used libraries
(Xft->XRender->Xlib) use different ways to get from an XRenderColor to
a XColor. One of them might use XParseColor with the rgb:rr/gg/bb
format, explaining how some people are getting #FFFFFF.
Received on Mon Mar 07 2022 - 15:23:50 CET