bug#25890: `color-values` gives wrong value

[Eli Zaretskii]

> Date: Sat, 04 Mar 2017 15:24:00 +0100
> From: Simen Heggestøyl <simenheg@gmail.com>
> Cc: 25890-done@debbugs.gnu.org
> 
> Thanks, Eli. The changes makes sense to me, but I've still got one
> problem. I'm working with web colors, where color codes are specified
> with either one or two digits per component (meaning that both "#fff"
> and "#ffffff" specify the brightest possible value, named
> "white"). But:
> 
> (apply #'color-rgb-to-hex `(,@(color-name-to-rgb "#ffffff") 2))
>      => "#fefefe"
> 
> (apply #'color-rgb-to-hex `(,@(color-name-to-rgb "#fff") 2))
>      => "#efefef"
> 
> Where I would like both to give back "#ffffff". Does this mean that I
> have to ensure that input to `color-name-to-rgb' uses 4 digits per
> component?

Yes, IMO.  Emacs does all its calculations with color components
assuming 16 bits per component.  Applications that need to use fewer
digits and have the missing digits as something other than zero, need
to do that in application code.

> Would it make sense for it to get a new optional parameter
> `DIGITS-PER-COMPONENT', like `color-rgb-to-hex' did?

Not IMO, because only the application knows what it means by #ffffff,
color.el has no way of knowing that.  So it would be best to leave
this for the application to do, by converting the #RGB spec to the
canonical 16-bits-per-component form.