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

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Mattias Engdegård <mattiase <at> acm.org>
Cc: tom <at> tromey.com, simon <at> polaris64.net, 41544 <at> debbugs.gnu.org
Subject: bug#41544: 26.3; Possible incorrect results from color-distance
Date: Thu, 04 Jun 2020 17:07:21 +0300

> From: Mattias Engdegård <mattiase <at> acm.org>
> Date: Wed, 3 Jun 2020 22:08:46 +0200
> Cc: Tom Tromey <tom <at> tromey.com>, Simon Pugnet <simon <at> polaris64.net>,
>         41544 <at> debbugs.gnu.org
> 
> Now about the consolidation of the contrast colour predicate (color-dark-p): as described previously in detail, the current code for doing so in various places is unsatisfactory. For example, some of the methods employed classify #00ff00 as a "dark" colour, leading to suboptimal results. (Try typing #00ff00 in css-mode.)

Let's please discuss each problem in detail (I tried to understand
them from the log message you posted, but couldn't find rationale
there).

And in any case, I will prefer solutions that fix any problems
locally, not changes in low-level stuff used in many other places,
because the latter run the risk of introducing new bugs.  As the
problems are quite minor, AFAICT, solving them in unsafe ways is
something to be avoided.

> There are other bugs that are annoying in themselves, but need to be fixed in order to make progress. Start Emacs in TTY mode with TERM=xterm-color and evaluate (color-name-to-rgb "blue"). Notice how one of the components is greater than 1 -- this is the unfortunate result of several bad decisions.

You mean, the component that is 1.0393?  What bad decisions caused
that, what problems does this small deviation causes in itself?  We
should weigh the gravity of the problems we try to solve here with the
potential of breaking working code elsewhere which relies on these
idiosyncrasies.

Thanks.

Previous Next

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