"Eli Zaretskii" <[EMAIL PROTECTED]> writes:
> > From: Dan Nicolaescu <[EMAIL PROTECTED]>
> > Date: Wed, 06 Apr 2005 01:17:11 -0700
> >
[snip]
> So I think the code in tty-colors.el is correct in this matter. It
> is, however, possible that the RGB values in color-name-rgb-alist were
> incorrectly scaled from 8-bit variants, and need to be amended.
Agreed. The problem seems to be that tty-colors.el and color-name-rgb-alist
don't use the same of scaling.
Do you want me to do check if rescaling the values in
color-name-rgb-alist gives good results?
>
> > With this fixes the gray colors are mapped linearly, and so are the
> > red1, blue1 and green1 colors (I checked the pixels in a screenshot).
>
> Does ``this fix'' above refer to the changes in xterm.el alone, or to
> the change in tty-colors.el as well? I think we should make the
> changes in xterm.el, but not in tty-colors.el.
By "fixes" I meant all the patches that I posted together, I did not
test them separately. (anyway the tty-colors.el patch should have zero
influence on what I saw because AFAICT that code path is only used
when creating a color from #RGB, xterm-register-default-colors does
its own scaling).
If you don't want the tty-colors.el changes, then ene of the changes
in xterm.el, the one to xterm-rgb-convert-to-16bit is not good, it
should be
(lsh prim 8)
instead of:
(logior prim (lsh prim 8))
The patch to xterm-standard-colors is obviously correct, so I could
check that in right now if you want.
> > Some standard face definitions use colors like "red" or "blue". They
> > should be changed "red1" (or "blue1")
>
> Yes, I agree. Can you post a patch to do that?
Will do.
> And thank _you_ for working on this.
Well that you too, our private mail discussion put me on the right
track to find out what the problem was.
--dan
_______________________________________________
Emacs-devel mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/emacs-devel
