GNU bug report logs - #36304
27.0.50; request: switch to the superior HTML #RGB convention for colors

Previous Next

Full log

View this message in rfc822 format

From: Pip Cet <pipcet <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rms <at> gnu.org, 36304 <at> debbugs.gnu.org
Subject: bug#36304: 27.0.50; request: switch to the superior HTML #RGB convention for colors
Date: Sat, 22 Jun 2019 14:41:30 +0000

On Sat, Jun 22, 2019 at 12:36 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > From: Pip Cet <pipcet <at> gmail.com>
> > Date: Sat, 22 Jun 2019 12:13:20 +0000
> > Cc: rms <at> gnu.org, 36304 <at> debbugs.gnu.org
> >
> > It'd leave us inconsistently still using the X standard in some
> > places, but at first glance they appear to be documented to use the X
> > standard, so maybe that's not wrong.
>
> I'm not sure I understand what you mean by "the X standard".  Is that
> the old or the new convention of how to interpret a given #RGB value?

The old convention, of interpreting #f00 as #f00000.

> > > I think we assume this color handling also in xfaces.c
> >
> > Only via tty-color-standard-values, as far as I can see.
> >
> > > and in lisp/term/tty-colors.el (and perhaps elsewhere, where TTY colors are used/defined).
> >
> > tty-color-standard-values is documented to use the X convention, and
> > it does. tty-color-desc is documented to return approximate results,
> > and it does;
>
> So we would need to change that as well, no?

We could. I don't have an opinion either way.

> > and it's only used for text terminals, right?
>
> Yes, but we nowadays support text terminals that can display 24-bit
> colors, and having their colors display differently from the same
> color on X is just asking for bug reports.

Okay, let's change it, then.

> > >  There's also lisp/color.el.
> >
> > Anything in particular? As far as I can tell, the functions work
> > properly using the new convention with this patch, although I am sure
> > there are places that fail to deal with the 65280-as-maximum
> > convention that nsfns.m uses.
>
> If you convert a color to RGB and then back, is the result equal to
> what you started with?  E.g., see

On my system, yes.

>   https://debbugs.gnu.org/cgi/bugreport.cgi?bug=29456#11
>
> Or what about issues discussed in bug#25890 and bug#24273?

Thanks for pointing me to those. I don't think the situation gets any
worse for those, at least.

> > > Am I missing something?
> >
> > I don't think so, but I don't see anything, so far, that needs
> > changing. I'm almost certain that some more places will need changing,
> > but how do we find them?
>
> By searching the code for "rgb" (case-insensitively)?

I've done that, now. No new problems that I've seen, though
gtkutil.c's xg_get_pixbuf_from_surface confuses me.

> E.g., what does
> parse_rgb_list return when the RGB value doesn't specify all the bits?
> what about color_distance? etc.

Those two are fine, as far as I can see; I know that you meant to
provide only examples, but if you have any hints for finding places
that need changing, please let me know.

> My point is that the "old" interpretation of the #RGB values might
> have seeped into more places than just that one xterm.c function, and
> if we are going to change the interpretation, we should make sure we
> do that consistently in all the affected places.

I don't think there's a way we can be absolutely certain to have fixed
every potential problem, but we should try, yes.

Previous Next

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