--- Begin Message ---
|
Subject: |
25.1.50; Unexpected return value from `color-name-to-rgb' |
|
Date: |
Sat, 20 Aug 2016 11:47:19 +0200 |
The docstring for `color-name-to-rgb' states the following:
"Normally the return value is a list of three floating-point numbers,
(RED GREEN BLUE), each between 0.0 and 1.0 inclusive."
When passing the hex value for white the return value is as expected:
(color-name-to-rgb "#ffffff")
⇒ (1.0 1.0 1.0)
But when passing the name of the same color, the return value becomes
different:
(color-name-to-rgb "white")
⇒ (1.00390625 1.00390625 1.00390625)
In GNU Emacs 25.1.50.134 (x86_64-pc-linux-gnu, GTK+ Version 3.20.7)
of 2016-08-20 built on x240
Repository revision: a4ba426d25bd6a5cbe11d81b82a789b8a2c948ed
Windowing system distributor 'The X.Org Foundation', version 11.0.11804000
System Description: Debian GNU/Linux testing (stretch)
Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND DBUS GSETTINGS NOTIFY GNUTLS LIBXML2
FREETYPE XFT ZLIB TOOLKIT_SCROLL_BARS GTK3 X11
Important settings:
value of $LANG: en_US.UTF-8
locale-coding-system: utf-8-unix
Major mode: Lisp Interaction
Minor modes in effect:
tooltip-mode: t
global-eldoc-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
line-number-mode: t
transient-mark-mode: t
Load-path shadows:
None found.
Features:
(shadow sort mail-extr ispell emacsbug message subr-x puny seq byte-opt
gv bytecomp byte-compile cl-extra help-mode cconv cl-loaddefs pcase
cl-lib dired dired-loaddefs format-spec rfc822 mml easymenu mml-sec
password-cache epa derived epg epg-config gnus-util rmail rmail-loaddefs
mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils
mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr
mail-utils time-date mule-util tooltip eldoc electric uniquify
ediff-hook vc-hooks lisp-float-type mwheel term/x-win x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list newcomment elisp-mode lisp-mode prog-mode register page
menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core term/tty-colors frame cl-generic cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese charscript case-table epa-hook
jka-cmpr-hook help simple abbrev obarray minibuffer cl-preloaded nadvice
loaddefs button faces cus-face macroexp files text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote dbusbind inotify dynamic-setting
system-font-setting font-render-setting move-toolbar gtk x-toolkit x
multi-tty make-network-process emacs)
Memory information:
((conses 16 99389 6019)
(symbols 48 20750 0)
(miscs 40 46 109)
(strings 32 18640 5788)
(string-bytes 1 591726)
(vectors 16 13763)
(vector-slots 8 450400 3027)
(floats 8 183 16)
(intervals 56 195 0)
(buffers 976 11)
(heap 1024 35065 1072))
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#25890: `color-values` gives wrong value |
|
Date: |
Fri, 03 Mar 2017 16:08:35 +0200 |
> From: Rasmus <address@hidden>
> Date: Wed, 01 Mar 2017 10:55:22 +0100
>
> Eli Zaretskii <address@hidden> writes:
>
> > I think there's a bug in color.el: it assumes that the #RGB notation
> > uses 24 bits, i.e. each component maxes out at 255. But Emacs does
> > its color calculations based on 16-bit components, which max out at
> > 65535, which is why #ffffff does NOT produce (65535 65535 65535), the
> > white color. (We decided long ago to use 16-bit components because X
> > APIs such as XParseColor on some systems, including yours, work with
> > such components.) IOW, #ffffff is parsed as #ff00ff00ff00, and that
> > is not "white".
> >
> > So I think the patch below is what is needed to fix this problem. Can
> > you try it? (There's one user of the functions the patch changes,
> > shr-color.el, which will need to be adapted to the change, if we
> > decide to install it.)
>
> The test I used before now works for me:
>
> (set-frame-parameter (selected-frame) 'background-color
> (color-darken-name "light yellow" 5))
>
> Other noteworthy effects of the change were already addressed by Michael.
Thanks, I installed my change with minor variations, and I'm marking
this bug done.
--- End Message ---