From konsole-devel Sun Sep 10 19:08:45 2006 From: lars.doelle () on-line ! de Date: Sun, 10 Sep 2006 19:08:45 +0000 To: konsole-devel Subject: Re: [Konsole-devel] [Bug 131770] no bold is displayed in konsole Message-Id: <200609102108.45422.lars.doelle () on-line ! de> X-MARC-Message: https://marc.info/?l=konsole-devel&m=115791537110192 > ------- Additional Comments From kurt.hindenburg kdemail net 2006-09-08 18:09 ------- > So the patch from #11 is O.K. and the patch from #20 is O.K.? Naa -- patch #11 breaks the rendition pipeline only further, additionally ignoring the bold information in the schema files on top of the already existing bug. Patch #12 fixes that the bold information faultily got send to the background. I introduced the problem during the addition of the 8 and 24 bit color modes through a copy/paste error from the transparency predicate, right above, which is a background attribute. > Testing with tests/colortest.sh I get bold for 30-39; however, 90-97 do NOT look like bold. Testing with "Konsole Default" (and looking at the code (effectiveRendition)) shows, that bold is respected by reverting to faint colors. SGR 90-97, 100-107 is an aixterm 16 color extension, adopted by xterm, and added to the konsole as a contribution aside, but never balanced with bold more than the test shows. I agree that the rendition is not optimal, because, e.g. 35 = 95+bold 35+bold = 95 xterm, b.t.w., is likely suboptimal here, e.g. 35+bold = 95+bold The later identity is introduced, because bold implies intensive in xterm, so the intensive information is lost when using the upper 8 color of the 16 color schema. Likely, intensity (or bold) information is lost in the konsole using 90-97, but in a different way. The superficial reason that both terminal lack here, is, that the codes where just added as a matter aside on top of the already existing handling. The codes are only private aixterm extensions, liberally supported by xterm and konsole. Deeper reason is, that there is no intense rendition attribute in VT102 and friends at all. Following the relevant ECMA definition, see http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-048.pdf I marked the codes implemented by the konsole there with a "*". -- snip 8< --------------------------- 8.3.117 SGR - SELECT GRAPHIC RENDITION Notation: (Ps...) Representation: CSI Ps... 06/13 Parameter default value: Ps = 0 SGR is used to establish one or more graphic rendition aspects for subsequent text. The established aspects remain in effect until the next occurrence of SGR in the data stream, depending on the setting of the GRAPHIC RENDITION COMBINATION MODE (GRCM). Each graphic rendition aspect is specified by a parameter value: * 0 default rendition (implementation-defined), cancels the effect of any preceding occurrence of SGR in the data stream regardless of the setting of the GRAPHIC RENDITION COMBINATION MODE (GRCM) * 1 bold or increased intensity 2 faint, decreased intensity or second colour 3 italicized * 4 singly underlined * 5 slowly blinking (less then 150 per minute) 6 rapidly blinking (150 per minute or more) * 7 negative image 8 concealed characters 9 crossed-out (characters still legible but marked as to be deleted) 10 primary (default) font 11 first alternative font 12 second alternative font 13 third alternative font 14 fourth alternative font 15 fifth alternative font 16 sixth alternative font 17 seventh alternative font 18 eighth alternative font 19 ninth alternative font 20 Fraktur (Gothic) 21 doubly underlined * 22 normal colour or normal intensity (neither bold nor faint) 23 not italicized, not fraktur * 24 not underlined (neither singly nor doubly) * 25 steady (not blinking) 26 (reserved for proportional spacing as specified in CCITT Recommendation T.61) * 27 positive image 28 revealed characters 29 not crossed out * 30 black display * 31 red display * 32 green display * 33 yellow display * 34 blue display * 35 magenta display * 36 cyan display * 37 white display * 38 (reserved for future standardization; intended for setting character foreground colour as specified in ISO 8613-6 [CCITT Recommendation T.416]) * 39 default display colour (implementation-defined) * 40 black background * 41 red background * 42 green background * 43 yellow background * 44 blue background * 45 magenta background * 46 cyan background * 47 white background * 48 (reserved for future standardization; intended for setting character background colour as specified in ISO 8613-6 [CCITT Recommendation T.416]) * 49 default background colour (implementation-defined) 50 (reserved for cancelling the effect of the rendering aspect established by parameter value 26) 51 framed 52 encircled 53 overlined 54 not framed, not encircled 55 not overlined 56 (reserved for future standardization) 57 (reserved for future standardization) 58 (reserved for future standardization) 59 (reserved for future standardization) 60 ideogram underline or right side line 61 ideogram double underline or double line on the right side 62 ideogram overline or left side line 63 ideogram double overline or double line on the left side 64 ideogram stress marking 65 cancels the effect of the rendition aspects established by parameter values 60 to 64 -- snap 8< --------------------------- As you can see from SGR-1, bold and intensive is already confused in the underlying standard of every terminal of this class, be it VT102, linux-console, xterm or konsole. Other attributes, like 60-63 are a likely overloaded. 90-107 SGR codes, which complete the list of implemented rendition codes in the konsole are a non-standard extensions, in some way introducing some sort of "intense" attribute. These codes do not exist, really, but are a private extension, only not made explicit as such. I doubt so, that these codes are ever emitted in any environment, but a remote shell to an AIX system. Curses, the terminal API, defines the attributes more orthogonally, see man:attr(3ncurses): A_NORMAL Normal display (no highlight) A_STANDOUT Best highlighting mode of the terminal. A_UNDERLINE Underlining A_REVERSE Reverse video A_BLINK Blinking A_DIM Half bright A_BOLD Extra bright or bold A_PROTECT Protected mode A_INVIS Invisible or blank mode A_ALTCHARSET Alternate character set A_CHARTEXT Bit-mask to extract a character COLOR_PAIR(n) Color-pair number n so it might appear as if all these independent attributes exist in all terminals, but curses handles different strands of terminals, e.g. wyse, too. Though curses would be able to spell bold and intensive separately, the terminfo translation would not preserve this for xterm, linux console, konsole, etc.. Note that even here, "A_BOLD" is of dubious semantics. The question is, what to do about it. I doubt, if anyone would care if things were left as they are, since only 8+1 colors are really defined, and the problem appears at the edge of a very weakly defined extension in an anyway sketchy model. One could go and put things more straight, introducing some proper intensive attribute, but this would require some reconciliation with maintainers of other terminals, if one does not want to make the mess even worse. -lars _______________________________________________ konsole-devel mailing list konsole-devel@kde.org https://mail.kde.org/mailman/listinfo/konsole-devel