bug#41544: 26.3; Possible incorrect results from color-distance

["Simen Heggestøyl" <simenheg@runbox.com>]

Eli Zaretskii <eliz@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