GNU bug report logs - #41544
26.3; Possible incorrect results from color-distance

Previous Next

Package: emacs;

Reported by: Simon Pugnet <simon <at> polaris64.net>

Date: Tue, 26 May 2020 16:34:01 UTC

Severity: normal

Tags: patch

Found in version 26.3

Full log


View this message in rfc822 format

From: Simen Heggestøyl <simenheg <at> runbox.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Richard Copley <rcopley <at> gmail.com>, Mattias Engdegård <mattiase <at> acm.org>, 41544 <at> debbugs.gnu.org
Subject: bug#41544: 26.3; Possible incorrect results from color-distance
Date: Sun, 07 Jun 2020 11:04:30 +0200
Eli Zaretskii <eliz <at> gnu.org> writes:

>> -(defun css--contrasty-color (name)
>> -  "Return a color that contrasts with NAME.
>> -NAME is of any form accepted by `color-distance'.
>> -The returned color will be usable by Emacs and will contrast
>> -with NAME; in particular so that if NAME is used as a background
>> -color, the returned color can be used as the foreground and still
>> -be readable."
>> -  ;; See bug#25525 for a discussion of this.
>> -  (if (> (color-distance name "black") 292485)
>> -      "black" "white"))
>> -
>>  (defcustom css-fontify-colors t
>>    "Whether CSS colors should be fontified using the color as the background.
>>  When non-`nil', a text representing CSS color will be fontified
>> @@ -1199,7 +1188,8 @@ css--fontify-region
>>  		    (add-text-properties
>>  		     start (point)
>>  		     (list 'face (list :background color
>> -				       :foreground (css--contrasty-color color)
>> +				       :foreground (readable-foreground-color
>> +                                                    color)
>>  				       :box '(:line-width -1))))))))))))
>>      extended-region))
>
> Here, once again I will ask what practical problem is being fixed.

I can't comment on the patch overall, but this part at least seems to
address Richard Copley's complaints in bug#30295. A dark foreground is
now used for #0f0/rgba(0,255,0,0.5) and #5e5 as Richard requested, which
indeed looks more readable to me too.

Maybe the pendulum has swung too far however. For instance, a dark
foreground is now used for #ef716e, which I think was easier to read
with the light foreground used before. Could that be fixed by tweaking
the cut-off values in color-dark-p, perhaps?

-- Simen




This bug report was last modified 4 years and 304 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.