I use below to compute adjusted colors given that lighten doesn't work when black multipliers are all zero. (defun my/color-rgb-transform-by-frac (c1 c2 frac) "Compute RGB color from C1 adjusted closer to C2 by FRAC. FRAC is a floating-point number between 0 and 1." (cl-destructuring-bind (c1-r c1-g c1-b) c1 (cl-destructuring-bind (c2-r c2-g c2-b) c2 (list (+ c1-r (* (- c2-r c1-r) frac)) (+ c1-g (* (- c2-g c1-g) frac)) (+ c1-b (* (- c2-b c1-b) frac)))))) (defun my/color-hex-transform-by-frac (c1 c2 frac) "Compute hex color from C1 adjusted closer to C2 by FRAC. FRAC is a floating-point number between 0 and 1." (apply #'color-rgb-to-hex (my/color-rgb-transform-by-frac (color-name-to-rgb c1) (color-name-to-rgb c2) frac))) ;; e.g., (my/color-hex-transform-by-frac "black" "white" 0.10) ; produces "#199919991999" (color-lighten-name "black" 10) ; produces "#000000000000" On Mon, Oct 28, 2024 at 8:40 AM Eli Zaretskii wrote: > > From: Gerd Möllmann > > Date: Mon, 28 Oct 2024 09:27:29 +0100 > > > > The function color-lighten-name doesn't work as I would expect for > > black: > > > > (color-lighten-name "#000000" 50) > > => "#000000000000" > > > > I think there is even a test that checks that, in color-tests.el: > > > > (ert-deftest color-tests-lighten-name () > > (should (equal (color-lighten-name "black" 100) "#000000000000")) > > > > I don't understand this, and it is different from what I'd expect, and > > tools for the web return, for example > > > > https://mdigi.tools/lighten-color/#000000 > > Our notion of "lighten color" seems to be to increase the color's > luminance by P percent. Since the black color's luminance is zero, > increasing that by 50% still yields zero. > > By contrast, the page you point to seems to interpret "lighten" to > mean that P is the percentage of the full scale, not of the original > color's luminance. > > This goes back to commit 656c2dd66e, which was supposed to fix > bug#54514. But maybe Noah's interpretation of "lighten" was > incorrect, and we should revert that change? OTOH, if we do revert > it, then Noah's example will disagree with the above page. > > So I guess our algorithm is incorrect somewhere? > > Adding Julien and Mattias, in the hope that they could help unconfuse > us. > > > >