Re: master 64e25cd: More robust NS hex colour string parsing

[Pip Cet]

Mattias Engdegård <mattiase@acm.org> writes:

> 12 juni 2020 kl. 19.33 skrev Eli Zaretskii <eliz@gnu.org>:
>
>> Were the 4 versions identical or different?  If the latter, what were
>> the differences, and which of the features that call them will from
>> now on behave differently?
>
> They were not semantically equivalent but clearly intended to be.

Only quite recently; the X version was changed to use the standard
scaling convention (#fff means white) a while back, and at the time I
preferred the approach of still letting Xlib handle the request, and
passing through whatever nonsensical values we might have gotten after
the '#' verbatim.

That said, I think there's currently a standard interpretation of 16-bit
color values (sRGB or something close enough), and I see no harm in your
proposed change provided that this is so (I think it's probably a good
idea to have things in one place so we can change it to a better color
representation once the technology is there. L-a-b is essentially
equivalent to RGB, except the components may be negative (not all of
them, obviously), so if we move to using three floats for representing a
color, they shouldn't be required to be strictly in the [0,1] range.)