1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
|
[README.color.schema]
Having made parts of the rendition process configurable, some explanation
seem to be required, to. Since I'm writing a color schema configuration
program in the moment, these notes are also some of the preparations for it.
First of all, the redition process deals with a lot of parameters, making
a useful configuration program for it quite complicated.
Looking at TECommon.h, the current implementation of a character cell allows
not less then 256 different foreground and background colors, together with
256 rendition values, with, forming a bit vector can be treated as 8 different
rendition attributes (like blink, bold, underlined, etc.)
[From the later, one already sees one misconception within the current
implentation. Attributes like bold, underlined, etc. belong to font.
Now because we do not have a proper terminal font family, this goes
into the rendition attributes instead. Sooner or later, no way will
lead around getting a proper family of scalable fonts for konsole.]
Upon further investigation one has carefully to distinguish between
the ability of the protocol to express rendition and the abilities of
the terminal widget to do them.
The protocol is able to express 18 different colors, this is 8 colors
taken from an RBG cube and an additional default color (which is intentionally
one of the 8 but it needn't be) both for fore- and background.
For simplicity, we interpret the fore- and background colors of the RGB cube
to be identical, thus ending up with 10 different colors (8 RBG + 2 default).
Note that this is not necessary, but just konsole's interpretation, it may
well make quite a lot of sense to have different sets of (real) colors for fore-
and background.
Now the xterm protocol can further express the following attributes:
- bold
- underlined
- blink
- reverse
The Linux console protocol knows also the attribute
- half-bright
Now, when it comes to interpretation, things become pretty messed up.
Xterm interprets "bold" as "font bold" + "foreground intensive"
Linux interprets "bold" as "foreground intensive"
Xterm interprets "blink" as nothing
Linux interprets "blink" as "background intensive"
Xterm interprets "underlined" as "font underlined"
Linux interprets "underlines" as "foreground intensive"
Xterm interprets "half-bright" as nothing
Linux interprets "half-bright" as "foreground dim"
ANSI interprets "half-bright" as "font italic"
all interprets "reverse" as "exchange fore- and background color"
A flexible interpretation engine is needed to cope with all this.
A proper configuration should also take care of it.
Since intensive and faint colors can also be expressed by the protocols,
the number of colors double or tripple (we do not have implemented
half-bright, yet, since we've just started to do the Linux console emulation.)
Note that the protocol is not able to express "intense", which causes part
of the confusion listed above. Xterms interpretation of bold as intensive+bold
is most probably caused by the fact, that in a black on white color display
(which is their default), "black" cannot be intensified, thus the attribute
would get lost. Linux gets around this problem by having the regular black as
dark gray, and only intensive black as black.
As a matter of personal taste, the author strongly dislikes the apparence of
the this combination when it comes to colorful applications. Thus the default
schema of konsole is configured to render only the default foreground color
as bold, while the others are rendered intensive. By this, the interpretation
device (and it's configuration) is even more complex as it appears above.
Konsole's rendition engine is currently not able to cope with font attributes
by changing the font. Instead, it does some (costly) operations with the
character images themselves to produce:
- bold
- underlined
It cannot render italic and is (by a parameter) limited to 20 different
colors. That fore- and background colors are interpreted identically, is
also build-in to the engine (and interpretation). These aren't severe
limitations, it can be changed easily.
Other then the emulations mentioned above, konsole can interpret "blink"
as blink. Just to have a little more fun, konsole can display background
images, meaning that some background colors have to be interpreted as
"transparent" when a background image exists. Practically, this can only
be the default background color, so a least this one could be hard-wired.
To set up a proper configuration, I do not want the users to cope with
all this unnecessary complications. Instead, a approach has to be found,
that allows to configure the already existing interpretations and other,
that do make sense. As stated above, it does not make sense individual
colors beside the default background colors to become transparent. Nor
does it make sense, to set all the 52 possible colors individually, since
an RGB color cube is intented with some intensity attributes. Some
experimentation is certainly necessary to get things right. E.g. VGA and
X11 colors are different for one of the yellow sorts, beside just being
gamma corrected.
|
