From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Richard Copley Newsgroups: gmane.emacs.devel Subject: Re: CSS contrast (#30295) (was Re: Heads-up: Emacs 26.1 RC1) Date: Wed, 21 Mar 2018 14:24:50 +0000 Message-ID: References: <83muz2lfo9.fsf@gnu.org> <837eq5lvyx.fsf@gnu.org> <83y3ilk32z.fsf@gnu.org> <83vadpk10e.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="f4f5e808c768ffdaf10567ecf5ab" X-Trace: blaine.gmane.org 1521642243 15921 195.159.176.226 (21 Mar 2018 14:24:03 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 21 Mar 2018 14:24:03 +0000 (UTC) Cc: John Wiegley , Tom Tromey , Emacs Development To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Mar 21 15:23:58 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eyeej-00041d-Dg for ged-emacs-devel@m.gmane.org; Wed, 21 Mar 2018 15:23:57 +0100 Original-Received: from localhost ([::1]:55446 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eyegm-0006Ij-KJ for ged-emacs-devel@m.gmane.org; Wed, 21 Mar 2018 10:26:04 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34091) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eyegE-0006Id-LQ for emacs-devel@gnu.org; Wed, 21 Mar 2018 10:25:31 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eyegA-0002pv-CO for emacs-devel@gnu.org; Wed, 21 Mar 2018 10:25:30 -0400 Original-Received: from mail-oi0-x230.google.com ([2607:f8b0:4003:c06::230]:39176) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eyeg5-0002nB-P6; Wed, 21 Mar 2018 10:25:22 -0400 Original-Received: by mail-oi0-x230.google.com with SMTP id q71-v6so4440624oic.6; Wed, 21 Mar 2018 07:25:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1IgvLqenYMJI6kVfbir5JtPLhmdxhH3wu5Jc/z4tzA8=; b=ssnproarz5P5QhGUABSqM3RLsp++f8Z65WapXn/9gWP1UQrYrFSTC20OW/NcqUH1jN xLNOhEmkXJQJ3N8sjqbhxkkWC36F6eXLzVooxjVdvmuMbxZW3AiO5JpET2aZ2FM2+a3d 7rVV53CczLXmX8NDcv7/A8cp4iVI7r/2JKvyubVzhFszoyIxVedhhXaYlMqzhgTBUj+I 2XwJqfOpNCDcwlUMaPNbQYfaoch7wY06GU9NyFG96Kf+vOOmpfFjVpMSBc7mDiILm8cg VaDIuilIBrZoEi7tP+yFratRK0GxzB3Y9HEHBMKSMnpjXQj9b4qP7j/zgD94/sJMrZJj 7zmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=1IgvLqenYMJI6kVfbir5JtPLhmdxhH3wu5Jc/z4tzA8=; b=IMSUcu4OYBdWeOkFFho6fo5dibM/QkU7N3mLhzf1zNQ2AweTcJzPYcr6xoSCvXgYA3 jB0bmJG/VzOJCoMwrtD/1A/sTuPFLvpft8PiStrrSYpl4NU3GXWqY8Y/SzR/b+3chAPH GXkkCizqcfXpGZAp2UOQk2xI1rj+kHbOErZSW9/krkFyk/Z1Ft9Ks4Gd2e8wLQw5/uf2 KxTsLBdTgRx7v9NeRo1LEL3Km7OTCyr3anH8IQ+OqFtBulUMYhAUm91+BOp8OG3yOiBz 7mJPsBNQBmv1m9SMkqgxh7mYMlLo4JaOIg/jKhU2dnVPd17oYQk8Xtxulvh2PvpaC78L WTDg== X-Gm-Message-State: AElRT7Ew3SmIv934Jap/hO1c031lQOjZNOMdfCUoH24Ugs8A4xRBD+V6 BQSekMZN6gy820sMLXMDjhvQMt+27/md8mQWasqVWtKo X-Google-Smtp-Source: AG47ELtCH4g9CmqpmuU+9ranclCAtl7nfEYd/yZUnTCbdUxH+PUk9saWOWIOApnpLZ/NsdBmaeC0sIl/00IjPTbPzkM= X-Received: by 10.202.27.1 with SMTP id b1mr12488567oib.110.1521642320679; Wed, 21 Mar 2018 07:25:20 -0700 (PDT) Original-Received: by 2002:a9d:4c87:0:0:0:0:0 with HTTP; Wed, 21 Mar 2018 07:24:50 -0700 (PDT) In-Reply-To: <83vadpk10e.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4003:c06::230 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:223892 Archived-At: --f4f5e808c768ffdaf10567ecf5ab Content-Type: text/plain; charset="UTF-8" On 21 March 2018 at 13:32, Eli Zaretskii wrote: > > From: Richard Copley > > Date: Wed, 21 Mar 2018 13:22:37 +0000 > > Cc: John Wiegley , Tom Tromey , > > Emacs Development > > > > We do something very similar in frame-set-background-mode and in > > tty-color-approximate. > > > > I don't see it. You're talking about this? > > > > ((>= (apply '+ (color-values bg-color frame)) > > ;; Just looking at the screen, colors whose > > ;; values add up to .6 of the white total > > ;; still look dark to me. > > (* (apply '+ (color-values "white" frame)) .6)) > > That's the first example, yes. > > > It's this particular way of using color-distance that we appear to > > have invented. > > Not according to the article from which the implementation of > color-distance was taken. ??? > If we didn't then we took it from > > somewhere else, and someone (Tom?) should know where. > > The comments in the sources of color-distance tell where we took it > from. > The comments, and the article, say where the colour distance formula itself comes from. The article doesn't support our usage of the formula at all. It says: >> This distance will only be used in comparisons, to verify whether one colour, *A*, is closer to colour *B* or to colour *C*. That's what my patch 1 does. It's nothing like what the current code does. > I don't believe the concept of a sphere centred on black is a useful one > in this context, or that allowing the > > user to vary its radius makes it any better. > > I suggest to read the original article mentioned above. > I suggest you re-read it. --f4f5e808c768ffdaf10567ecf5ab Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On 21 March 2018 at 13:32, Eli Zaretskii <eliz@gnu.org> wrot= e:
> From: Richard Copley <rcopley@gmail.com> > Date: Wed, 21 Mar 2018 13:22:37 +0000
> Cc: John Wiegley <johnw@gnu.org>, Tom Tromey <tom@tromey.com>,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Emacs Development <emacs-devel@gnu.org>
>
>=C2=A0 We do something very similar in frame-set-backgroun= d-mode and in
>=C2=A0 tty-color-approximate.
>
> I don't see it. You're talking about this?
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0((>=3D (apply '+ (color= -values bg-color frame))
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ;; Just looking= at the screen, colors whose
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ;; values add u= p to .6 of the white total
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ;; still look d= ark to me.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (* (apply '= + (color-values "white" frame)) .6))

That's the first example, yes.

> It's this particular way of using color-distance that we appear to=
> have invented.

Not according to the article from which the implementation of
color-distance was taken.

???

> If we didn't then we took it from
> somewhere else, and someone (Tom?) should know where.

The comments in the sources of color-distance tell where we took it<= br> from.

The comments, and th= e article, say where the colour distance formula itself comes from.
The = article doesn't support our usage of the formula at all.

<= div>It says:
>> This distance will only be used in comp= arisons, to verify whether one colour, A, is closer to colour B or to colour C.
That's what my patch 1 does. It's nothing like what = the current code does.

> I don't believe the concept of a sphere centred on black is a usef= ul one in this context, or that allowing the
> user to vary its radius makes it any better.

I suggest to read the original article mentioned above.

I suggest you re-read it.

--f4f5e808c768ffdaf10567ecf5ab--