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

[Pip Cet]

On Sat, Jun 22, 2019 at 12:36 PM Eli Zaretskii <eliz@gnu.org> wrote:
> > From: Pip Cet <pipcet@gmail.com>
> > Date: Sat, 22 Jun 2019 12:13:20 +0000
> > Cc: rms@gnu.org, 36304@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.