unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: "Mattias Engdegård" <mattias.engdegard@gmail.com>
Cc: gerd.moellmann@gmail.com, julien@danjou.info, noah@splode.com,
	74055@debbugs.gnu.org
Subject: bug#74055: 31.0.50; color-lighten-name not lightening black
Date: Mon, 28 Oct 2024 19:24:28 +0200	[thread overview]
Message-ID: <86cyjk6sz7.fsf@gnu.org> (raw)
In-Reply-To: <AF3FBB45-2036-4E85-B6A9-FC8F91F91D16@gmail.com> (message from Mattias Engdegård on Mon, 28 Oct 2024 17:57:49 +0100)

> From: Mattias Engdegård <mattias.engdegard@gmail.com>
> Date: Mon, 28 Oct 2024 17:57:49 +0100
> Cc: Gerd Möllmann <gerd.moellmann@gmail.com>,
>  Julien Danjou <julien@danjou.info>,
>  74055@debbugs.gnu.org,
>  Noah Friedman <noah@splode.com>
> 
> 28 okt. 2024 kl. 13.39 skrev Eli Zaretskii <eliz@gnu.org>:
> 
> > 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.
> 
> That change may have been made in haste. For example, it didn't touch the corresponding saturate and desaturate functions which use similar mechanics, so there is now an inconsistency in that respect.
> 
> But which interpretation is better isn't obvious. It doesn't have much to do with colour theory per se. As luminance is already a percentage of sorts, it's not at all clear what it means by increasing it by a certain percentage. Personally I wouldn't use either function because of how ill-defined they are.

Maybe there are widely-accepted de-facto standards for that?

Or maybe we should support more than one interpretation, by way of
some user option?





  reply	other threads:[~2024-10-28 17:24 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-28  8:27 bug#74055: 31.0.50; color-lighten-name not lightening black Gerd Möllmann
2024-10-28 12:39 ` Eli Zaretskii
2024-10-28 15:18   ` Ship Mints
2024-10-28 16:57   ` Mattias Engdegård
2024-10-28 17:24     ` Eli Zaretskii [this message]
2024-10-29  4:41       ` Gerd Möllmann
2024-10-29  8:25         ` Gerd Möllmann
2024-10-29 12:54       ` Mattias Engdegård
2024-10-29 18:27         ` Gerd Möllmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=86cyjk6sz7.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=74055@debbugs.gnu.org \
    --cc=gerd.moellmann@gmail.com \
    --cc=julien@danjou.info \
    --cc=mattias.engdegard@gmail.com \
    --cc=noah@splode.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).