Issue 218 in iterm2: Support for 3-byte color mode

[ite...@googlecode.com]

Status: New
Owner: ----
Labels: Type-Defect Priority-Medium

New issue 218 by doerwalter: Support for 3-byte color mode
http://code.google.com/p/iterm2/issues/detail?id=218

Are there plans to support 3-byte color mode (i.e. escape sequences that
directly switch the foreground or background color to a specified RGB
value)?

An example for a script can be found here:

http://github.com/robertknight/konsole/tree/master/tests/color-spaces.pl

and a description here:

http://github.com/robertknight/konsole/tree/master/user-doc/README.moreColors

(Note that this is the same feature request as
http://sourceforge.net/tracker/?func=detail&aid=2175555&group_id=67789&atid=518976
for
iTerm 1)

[ite...@googlecode.com]

Updates:
Labels: -Type-Defect Type-Enhancement

Comment #1 on issue 218 by gnachman: Support for 3-byte color mode
http://code.google.com/p/iterm2/issues/detail?id=218

Do any apps support this? Besides that, my only reservation is that it
would increase memory usage nontrivially.

[ite...@googlecode.com]

Comment #2 on issue 218 by doerwalter: Support for 3-byte color mode
http://code.google.com/p/iterm2/issues/detail?id=218

http://cheat.errtheblog.com/s/terminal_escapes/ states that "24-bit Color
codes appear only appear to be implemented for Konsole (a KDE / Linux
Terminal Emulator)". I know of no applications that uses 24bit (although I
would immediate start to use those escape sequences in my own shell
scripts ;)). Furthermore I don't know if curses supports 24bit mode.

[ite...@googlecode.com]

Updates:
Labels: -Priority-Medium Priority-Low

Comment #3 on issue 218 by gnachman: Support for 3-byte color mode
http://code.google.com/p/iterm2/issues/detail?id=218

(No comment was entered for this change.)

[ite...@googlecode.com]

Comment #4 on issue 218 by jonathan...@gmail.com: Support for 3-byte color
mode
http://code.google.com/p/iterm2/issues/detail?id=218

It's true that only Konsole supports that 24-bit color mode so far (AFAIK).
The problem is, without support for this, we're stuck with the 8-bit color
cube, which is pretty meager. It has, for instance, no nice dark green. And
it's not well-organized. There's no easy/good way to use human-sensible
color names (say of the X11 variety
(http://bradbury.org/jim/xtermcolors.html) or the even more important RGB
values specified for web programming (in HTML or CSS). Given today's
emphasis on Web output, this inability for developers to easily translate
to terminal color values means that colored terminal text is even less
likely to be supported by applications.

I do not see memory consumption to be a major impediment, given modern
system RAM sizes. But if you think it's an issue, use a CLUT (color lookup
table) approach. It's highly unlikely that any real terminal app would ever
use more than 256 colors. It's just that the 256 colors in the classical
8-bit ANSI set suck badly, and correlate so poorly to the colors used in
other apps. It appears from iterm2's loadable color profiles
(http://code.google.com/p/iterm2/wiki/ColorGallery) that it already
supports 24b definitions, just not as a part of program output.

So yes, please dollow Konsole's extension to 24b colors.

[ite...@googlecode.com]

Comment #5 on issue 218 by jonathan...@gmail.com: Support for 3-byte color
mode
http://code.google.com/p/iterm2/issues/detail?id=218

s/dollow/follow/g

[ite...@googlecode.com]

Comment #6 on issue 218 by oth...@gmail.com: Support for 3-byte color mode
http://code.google.com/p/iterm2/issues/detail?id=218

Vim has a custom build supports 24bit color[1] by ZyX.
A thinks Vim users will be very glad to have full color Vim theme shows on
their screen.

http://usevim.com/2013/05/31/24bit/

--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[ite...@googlecode.com]

Comment #7 on issue 218 by docw...@gmail.com: Support for 3-byte color mode
http://code.google.com/p/iterm2/issues/detail?id=218

My understanding is that konsole just takes the RGB tuple escape sequence
and instead of getting the nearest, it just uses it directly. From
http://search.cpan.org/~sharyanto/Color-ANSI-Util-0.01/lib/Color/ANSI/Util.pm#rgb_to_ansi256($color)_=>_STR

> BTW, ANSI code to set RGB foreground color (supported by
> Konsole/Yakuake): "\e[38;2;<R>;<G>;<B>m" and to set RGB background
> color: "\e[48;2;<R>;<G>;<B>m", where R, G, B are decimal values.

[ite...@googlecode.com]

Updates:
Labels: Milestone-Release3.0

Comment #8 on issue 218 by gnach...@gmail.com: Support for 3-byte color mode
http://code.google.com/p/iterm2/issues/detail?id=218

(No comment was entered for this change.)

[ite...@googlecode.com]

Comment #9 on issue 218 by fxb...@gmail.com: Support for 3-byte color mode
http://code.google.com/p/iterm2/issues/detail?id=218

Is this feature request being considered. It would be a really big win for
emacs people.

[ite...@googlecode.com]

Updates:
Status: Fixed

Comment #10 on issue 218 by gnach...@gmail.com: Support for 3-byte color
mode
http://code.google.com/p/iterm2/issues/detail?id=218

This is in the nightly build now!

[ite...@googlecode.com]

Comment #11 on issue 218 by u...@zuse.jp: Support for 3-byte color mode
http://code.google.com/p/iterm2/issues/detail?id=218

I think konsole style 3-byte color mode (separated by semi-colon) is
harmful.
If you want to support 24bit color with SGR sequence, the proper way is to
use colon separator (ITU T.416 style).

The Konsole-style SGR sequence breaks backword and forward compatibility.

It is clear that a Konsole-style sequence causes incorrect action on many
terminals that do not support it. In contrast, ITU T.416-style's one is
expected to be ignored by ideal ECMA-48 based terminals (that have
canonical control function parser).

And the Konsole style introducer "CSI 38/48 ; n ;" takes variable length
arguments, so this sequence can not extend safely. Actually, current
iTerm2's parser causes bad action when CMY/CMYK sequences. Imagine the
hardness of when someone propose a extension for YUV/HLS, with keeping
backward compatibility. A future terminal developer may curse us.

In that sense, the same can be said of xterm's 256-color extension (CSI
38 ; 5 ; n / CSI 48 ; 5 ; n). But that has already spread widely. We should
not repeat the same mistake.

[ite...@googlecode.com]

Comment #12 on issue 218 by fxb...@gmail.com: Support for 3-byte color mode
http://code.google.com/p/iterm2/issues/detail?id=218

Taking advantage of this feature under emacs would be really great. I
launched a thread on emacs-devel
http://lists.gnu.org/archive/html/emacs-devel/2013-09/msg00157.html

[ite...@googlecode.com]

Comment #13 on issue 218 by patrick...@gmail.com: Support for 3-byte
color mode
http://code.google.com/p/iterm2/issues/detail?id=218

As a Vim user i am raring to use true color in iTerm. Great to see that
there's something happening in this direction!

I downloaded the nightly build and used the perl script linked to in the
first post here to test it. Didn't seem to work for me. Do I have to enable
it first somehow?

[ite...@googlecode.com]

Comment #14 on issue 218 by gnach...@gmail.com: Support for 3-byte color
mode
http://code.google.com/p/iterm2/issues/detail?id=218

@zuse.jp, do any other terminals implement the ITU standard? Also, can you
give me an example of the bad CMY/CMYK sequence?

[ite...@googlecode.com]

Comment #15 on issue 218 by gnach...@gmail.com: Support for 3-byte color
mode
http://code.google.com/p/iterm2/issues/detail?id=218

@patrick, what do you see? It should just work.

[ite...@googlecode.com]

Comment #16 on issue 218 by sait...@gmail.com: Support for 3-byte color mode
http://code.google.com/p/iterm2/issues/detail?id=218

@gnachman, I'm sorry for late reply.

> do any other terminals implement the ITU standard?

AFAIK, the following terminals can parse ITU-T.416 style(colon separated)
SGR sequence.

- xterm
- TeraTerm http://ttssh2.sourceforge.jp/index.html.en
- RLogin http://nanno.dip.jp/softlib/man/rlogin/ctrlcode.html (Japanese)
- mlterm http://ttssh2.sourceforge.jp/index.html.en

(For more details, see
https://github.com/gnachman/iTerm2/blob/master/VT100Terminal.m#L647)

> Also, can you give me an example of the bad CMY/CMYK sequence?

Now we print "foreground color CMY [38,2,100] and background CMYK
[48,5,7,4]" in konsole-styled sequence.

echo -en "\033[38;3;38;2;255;48;4;48;5;7;4mabc"

It may bring hell to us.
Current iTerm2 interpret this as "foreground RGB [2,255,48], indexed
background color 7 and underlined attribute".
gnome-terminal will interpret this as "half-bright, inverse, and
underlined".

I do not know why we need to repeat the confusion of 15 years ago.
I prefer to abandon SGR sucks and propose new ECMA-48 compliant sequence,
such as

CSI ? R ; G ; B $ m

[ite...@googlecode.com]

Comment #17 on issue 218 by gnach...@gmail.com: Support for 3-byte color
mode
http://code.google.com/p/iterm2/issues/detail?id=218

Thanks for the clarification. This is quite a mess. I added support for
the : delimiters in 5294130. I think I should keep support for the ; method
since xterm supports it, which means people will expect it to work.