On Sun, 6 Mar 2022 21:07:41 +0800 Yutao Yuan <[email protected]> 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.
