[Konsole-devel] [Bug 107487] Please add the xterm-256 colour support.

[Lars Doelle]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=107487         




------- Additional Comments From lars.doelle on-line de  2006-06-07 13:33 -------
Andy,

i certainly do not want to overdo it, and i certainly do not want to stand in the
way of adding a useful feature.

I checked "ctlseqs.ms" from the xterm distribution meanwhile which defines the
sequence as follows:

---
                 Ps = 1 0 7  -> Set background color to White
...                
            If 88- or 256-color support is compiled, the following  apply.
                 Ps = 3 8  ; 5  ; Ps -> Set foreground color to the second Ps
                 Ps = 4 8  ; 5  ; Ps -> Set background color to the second Ps
---

This means, these xterm-"Ps" can only occure within one escape code.

Given that 38/48 are reserved selectors, chances of a collision are actually low.

No one ever fully implemented ECMA-48, which is a mixture of terminal and
printer codes, really. So i would only take it as a guide line, while upholding it
as good as possible.

The problem with the ECMA-48 definition is, that the colon used in a sub-parameter
would likely break any VT100 alike parser. May be, that is the reason why these
anomalous "Ps" where chosen for xterm.

I'll thus write to Thomas Dickey, the xterm maintainer, to learn about his point of view.

Additionally, i'll review the patch, meanwhile, which looks fine on the first glance,
in particular the change to parser material in TEmuVt102.cpp looks good. This
leaves default colors.

Problem here was most probably, that it breaks the format of the screen and history,
which uses one byte per color. Now 256+2 do not fit into a byte anymore. Solution
would be to extend the space per color to 2 bytes. The color have to be kept in indexed
format in history and screen to allow proper interpretation of the default colors and cannot
be translated to RGB. Perhaps one should reserve one byte to indicate the color space,
perhaps a few bits are left in the rendition attribute for that purpose...

> If my reading is correct, then the ISO/ITU standard has already broken 
> the "associativity" of the SGR parameters when used with 38 and 48. In light 
> of that, I think you might as well support setting colour the Xterm way as 
> well as the ISO standard way, since both ways are non-associative and by now 
> a lot of software expects things to work the Xterm way.
> 
> Xterm also supports redefining the colours in the 256-colour palette, with a 
> command like this:
> echo -e '\033]4;65;rgb:ff/00/00\033\\'
> 
> The 6x6x6 colour cube is just a convenient default.


Is the 6x6x6 color cube predefined, btw.?

> If Konsole gets 256-colour  
> support, it might be good to support those kinds of palette-setting 
> sequences, too.


Hmm, changing the color format has some consequences. E.g. are colors of text already
written supposed to be preserved or changed when the interpretation changes via ESC]4?
How is transparency to be dealt with in light of the extended color space?

-lars