apps/konsole/developer-doc/old-documents/color-schema

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