Version: (using KDE KDE 3.5.4) Installed from: Slackware Packages OS: Linux a sequence like echo "^[[1mNot bold^[[0m" where ^[ is typed with ctrl-v + esc is not dispayed in bold it should only in konsole from kde 3.5.4 (it works in kde 3.5.3)
It works here in KDE 3.5.4; what font are you using?
I can confirm this bug. Kubuntu 6.0.6 Konsole:1.6.4 (package 4:3.5.4-0ubuntu1~dapper2) Kde: 3.5.4 Work OK in 1.6.3, ie Not Bold is bold. Fonts tried: ProggyCleanTTSZ Andale Mono Bitstream Vera Sans Mono Schema: Xterm Color (Not bold echoed in grey, other text in black.) Konsole Default (Not bold echoed black, other text black) Is this bug caused by the fix: Add 256 color support. Fixes bug 107487. See SVN commit 557629.
Created attachment 17224 [details] some screen shot for the non believers or the one who does not know what bold means it does not work for either mono font i choose and try: bistream vera sans mono dejavu sans mono courier courier new
Same here, I'm afraid. My Konsole default font is Terminus size 9, which has a bold weight, however unlike Kate, Konsole no longer displays it. Also, while the bold weight is in fact in the list in the font selection dialog, when I click "Bold", size 9 suddenly disappears from the list of available sizes and it jumps to a larger size for the same font. KDE 3.5.4, Qt 3.3.6, FontConfig 2.3.95, FreeType 2.2.1.
*** Bug 131904 has been marked as a duplicate of this bug. ***
I compiled KDE from sources, it's extremely unlikely that the bug is in a dependency of KDE.
Curiously, if you select some text that should be bold, it's bold. Doesn't work otherwise (current 3.5 branch here), so I'm confirming this bug.
I second this. Selected text works.
Created attachment 17240 [details] Patch to enable bold Disregard my comment #1; bold has never worked for me. I have bold in my $PS1 and have never seen bold. If it did work for you, you were lucky :) The selecting text didn't change anything for me... For those who can recompile and test this patch I would appreciate it. konsole/tests/colortest.sh is a good script to test attributes.
This patch repairs the regression. Many thanks.
SVN commit 570194 by hindenburg: Fix to display bold. For those for whom bold worked in KDE 3.5.3, this is the regression fix. For those, like me, for whom bold never work, this is the fix. No patch is needed for KDE4 as bold works there. BUG: 131770 M +1 -1 TEScreen.cpp M +12 -0 TEWidget.cpp --- branches/KDE/3.5/kdebase/konsole/konsole/TEScreen.cpp #570193:570194 @@ -501,7 +501,7 @@ void TEScreen::effectiveRendition() // calculate rendition { - ef_re = cu_re & (RE_UNDERLINE | RE_BLINK); + ef_re = cu_re & (RE_UNDERLINE | RE_BLINK | RE_BOLD); if (cu_re & RE_REVERSE) { ef_fg = cu_bg; --- branches/KDE/3.5/kdebase/konsole/konsole/TEWidget.cpp #570193:570194 @@ -677,6 +677,18 @@ } // Paint text + if (attr->r & RE_BOLD) + { + QFont currentFont = paint.font(); + currentFont.setBold(true); + paint.setFont( currentFont ); + } else { + QFont currentFont = paint.font(); + currentFont.setBold(false); + paint.setFont( currentFont ); + } + + if (!(blinking && (attr->r & RE_BLINK))) { // ### Disabled for now, since it causes problems with characters
Bold works again, although it noticably differs in behavior from KDE 3.5.3's Konsole. My guess is that bold worked in earlier versions only for non-colored text. My bash prompt uses a "1;31" color code for one of its sections. With this patch, this is interpreted als "bold light red". In 3.5.3 and earlier versions, it was interpreted only as "light red". Despite that, bold text in the output of various command line utilities I use worked fine in 3.5.3 (and stopped working in 3.5.4). Interpreting it as "bold light red" is consistent with xterm, however. Time to find a light red that isn't bold for my prompt ;-)
Sounds accurate to me. The only bold I'd noticed and cared about for years was in my PS1, which is non-coloured. I've also noticed that directory names in 'ls' are showing up bold now, with --color=auto, which is consistent with xterm, so I'm inclined to believe this is a genuine improvement.
Now bold is indeed broken, but I hate to say that the fix below is not in order. > --- branches/KDE/3.5/kdebase/konsole/konsole/TEScreen.cpp #570193:570194 > @ -501,7 +501,7 @ > void TEScreen::effectiveRendition() > // calculate rendition > { > - ef_re = cu_re & (RE_UNDERLINE | RE_BLINK); > + ef_re = cu_re & (RE_UNDERLINE | RE_BLINK | RE_BOLD); > if (cu_re & RE_REVERSE) > { > ef_fg = cu_bg; The omission of RE_BOLD in the line above was a feature. The rendering might look like xterm now, but this is bad. Xterm interprets BOLD as intesive+bold. There are some oddities about intensive and bold throughout various emulations, and the original version was a carefully balanced treatment of this, now broken by the patch. See [konsole/doc/color-schema] for some notes on it. In general, the konsole interprets bold as intensive (like the linux console). Only in particular situation, when e.g. intensive black == regular black, bold is set. These exceptions are spelled in the *.schema files. This is subtile, but wanted, as it improves the overall impression quite a bit. I'll try to dig into the bug these days. -lars
Well - I was happy that this will be fixed and now I'm not so sure. I just want to have both bold/regular fonts in Vim + Konsole. If this is possible now, please tell me what should I do with .schema files to achieve what I want.
Dawid, > Well - I was happy that this will be fixed and now I'm not so sure. > I just want to have both bold/regular fonts in Vim + Konsole. I confirm that there is a bug, and that I'm out to fix it. It is only that the earlier fix was not right, and breaks the particular handling of bold vs. intensive in the konsole. The resulting interpretation is that of the xterm (bold = bold+intensive), which is plain ugly, and only hard to read. The interpretation of the konsole is 'bold = intensive', with some exceptions, when it comes to black-on-white and likely edge cases. These exceptions are spelled in the .schema files. Now the code handling of said exceptions is broken. > If this is possible now, please tell me what should I do with .schema > files to achieve what I want. The bug (and the proposed fix) implies, that the schema is not properly respected anymore, so you cannot do much tweaks there. The .schema files as they are should already do precisely what you demand, it there were not said bug. I'll find time these days to hunt the bug down. Please excuse the delay. -lars
Created attachment 17507 [details] Enabled bold in normal mode
the patch in comment #17 does not work when i apply it to kdebase-3.5.4. i.e. i got no bold in konsole back again. i will stick with the patch from comment #11
> The resulting interpretation > is that of the xterm (bold = bold+intensive), which is plain ugly, and only > hard to read. The interpretation of the konsole is 'bold = intensive', with > some exceptions, when it comes to black-on-white and likely edge cases. I implemented bold text along the lines of xterm in Konsole SVN and it looks fine in the standard white-on-black and black-on-white colour schemes with Vim, man, coloured ls output and others that I tried. One or two of the 'intensive' colours would work better if they were slightly different shades (eg. the 'intensive' green in the white-on-black scheme is a little too light), but other than that I cannot see a problem.
Hello, find attached a patch for the related bug. Note that the patch is against 3.5.4 and the earlier patch posted has to be reverted, since otherwise the whole mechanism would be broken. -- 8< snip ----------- --- konsole/TECommon.h.orig 2006-07-22 10:15:55.000000000 +0200 +++ konsole/TECommon.h 2006-09-03 19:10:21.000000000 +0200 @@ -219,8 +219,8 @@ inline bool ca::isBold(const ColorEntry* base) const { - return (b.t == CO_DFT) && base[b.u+0+(b.v?BASE_COLORS:0)].bold - || (b.t == CO_SYS) && base[b.u+2+(b.v?BASE_COLORS:0)].bold; + return (f.t == CO_DFT) && base[f.u+0+(f.v?BASE_COLORS:0)].bold + || (f.t == CO_SYS) && base[f.u+2+(f.v?BASE_COLORS:0)].bold; } #endif // TECOMMON_H -- 8< snap ----------- The bug had been introduced by me adding the 2^8 and 2^32 colour spaces, and is a copy-paste error, where i copied the above predicate from the related one for transparency, which is a background attribute, while bold is a foreground attribute, forgetting to adjust that. Sorry for the inconvenience. This also explains, why the bold attribute was visible during reverse rendering, i.e. during marking. As some delight came up on the earlier (wrong) fix about the result that it "brings konsole in line with the xterm rendering", some words of explanation: The interpretation of BOLD rendition is not really defined. Xterm interprets BOLD as INTENSIVE+BOLD, while the linux console interprets it as INTENSIVE, which, together with the fact that the white forground there is not intense-white, as in xterm, produces a more pleasing and eye-sparing appearance. The konsole sticks to later interpretation by default, though it is only the matter of picking a schema, for instance "Xterm Colours", to make the konsole look like xterm, so nothing new was introduces. To reiterate, xterm is in no way the only measure, and indeed, the konsole was also able to produce a pixel identical image of the linux-console screen. The earlier patch would have broken this feature more than it is anyway, right now. The particular way to interpret BOLD is coded in the *.schema files, which take care to handle the edge cases, in particalar, when e.g. intense black is used as default foreground colour. Such edge cases, where BOLD cannot be presented by INTENSIVE, are then handled as BOLD. Normally, a non-intensive colour is used and the former interpretation could be applied. I'm aware that this is a bit obscure, the following examples from the schema files should make this more understandable: -- 8< snip ----- # example scheme for konsole # the title is to appear in the menu. title Black on White # foreground colors # note that the default background color is flagged # to become transparent when an image is present. # slot transparent bold # | | | # V V--color--V V V color 0 0 0 0 0 0 # regular foreground color (Black) color 1 255 255 255 1 0 # regular background color (White) color 2 0 0 0 0 0 # regular color 0 Black color 3 178 24 24 0 0 # regular color 1 Red color 4 24 178 24 0 0 # regular color 2 Green color 5 178 104 24 0 0 # regular color 3 Yellow color 6 24 24 178 0 0 # regular color 4 Blue color 7 178 24 178 0 0 # regular color 5 Magenta color 8 24 178 178 0 0 # regular color 6 Cyan color 9 178 178 178 0 0 # regular color 7 White # intensive colors # instead of changing the colors, we've flaged the text to become bold color 10 0 0 0 0 1 # intensive foreground color color 11 255 255 255 1 0 # intensive background color color 12 104 104 104 0 0 # intensive color 0 color 13 255 84 84 0 0 # intensive color 1 color 14 84 255 84 0 0 # intensive color 2 color 15 255 255 84 0 0 # intensive color 3 color 16 84 84 255 0 0 # intensive color 4 color 17 255 84 255 0 0 # intensive color 5 color 18 84 255 255 0 0 # intensive color 6 color 19 255 255 255 0 0 # intensive color 7 -- 8< snap ----- Note that on in colour 10, the "bold attribute" is set on, meaning that this colour should also render bold. Both colours 0 and 1 and colours 10 and 11 are used for the default colours, the first couple for normal the second for bold rendering. Now because colour 0 (default foreground) and colour 10 (default foreground + BOLD) spell the same colour (intense black), bold rendering has been flagged, taking care of this edge case. An xterm compliant rendering is achieved by using the "Xterm Colour" schema, listed below -- 8< snip ----- # xterm color schema for konsole # xterm colors can be configured (almost) like # konsole colors can. This is the uncustomized # xterm schema. # Please refere to your local xterm setup files # if this schema differs. title XTerm Colors # foreground colors ------------------------------- # note that the default background color is flagged # to become transparent when an image is present. # slot transparent bold # | red grn blu | | # V V--color--V V V color 0 0 0 0 0 0 # regular foreground color (Black) color 1 255 255 255 1 0 # regular background color (White) color 2 0 0 0 0 0 # regular color 0 Black color 3 205 0 0 0 0 # regular color 1 Red color 4 0 205 0 0 0 # regular color 2 Green color 5 205 205 0 0 0 # regular color 3 Yellow color 6 0 0 205 0 0 # regular color 4 Blue color 7 205 0 205 0 0 # regular color 5 Magenta color 8 0 205 205 0 0 # regular color 6 Cyan color 9 229 229 229 0 0 # regular color 7 White # intensive colors ------------------------------------------- # for some strange reason, intensive colours are bold, also. color 10 77 77 77 0 1 # intensive foreground color color 11 255 255 255 1 1 # intensive background color color 12 77 77 77 0 1 # intensive color 0 color 13 255 0 0 0 1 # intensive color 1 color 14 0 255 0 0 1 # intensive color 2 color 15 255 255 0 0 1 # intensive color 3 color 16 0 0 255 0 1 # intensive color 4 color 17 255 0 255 0 1 # intensive color 5 color 18 0 255 255 0 1 # intensive color 6 color 19 255 255 255 0 1 # intensive color 7 -- 8< snap ----- Note that here, all intense colours are also rendered bold. -lars Created an attachment (id=17629) konsole%7ETEComm.pat
Great explanation Lars, I can confirm this properly fixes the bug.
So the patch from #11 is O.K. and the patch from #20 is O.K.? Testing with tests/colortest.sh I get bold for 30-39; however, 90-97 do NOT look like bold.
> ------- 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
SVN commit 582860 by hindenburg: Revert my attempt to fix bold, 570194. CCBUG: 131770 M +1 -1 TEScreen.cpp M +0 -13 TEWidget.cpp --- branches/KDE/3.5/kdebase/konsole/konsole/TEScreen.cpp #582859:582860 @@ -506,7 +506,7 @@ void TEScreen::effectiveRendition() // calculate rendition { - ef_re = cu_re & (RE_UNDERLINE | RE_BLINK | RE_BOLD); + ef_re = cu_re & (RE_UNDERLINE | RE_BLINK); if (cu_re & RE_REVERSE) { ef_fg = cu_bg; --- branches/KDE/3.5/kdebase/konsole/konsole/TEWidget.cpp #582859:582860 @@ -684,19 +684,6 @@ } } - // Paint text - if (attr->r & RE_BOLD) - { - QFont currentFont = paint.font(); - currentFont.setBold(true); - paint.setFont( currentFont ); - } else { - QFont currentFont = paint.font(); - currentFont.setBold(false); - paint.setFont( currentFont ); - } - - if (!(blinking && (attr->r & RE_BLINK))) { // ### Disabled for now, since it causes problems with characters
SVN commit 583168 by hindenburg: Patch dealing with bold and the 256 colors issues by Lars Doelle. Read the comments from lars on the bug report for more info about bold/intensive colors in KDE 3.5.x. CCBUG: 131770 M +2 -2 TECommon.h --- branches/KDE/3.5/kdebase/konsole/konsole/TECommon.h #583167:583168 @@ -227,8 +227,8 @@ inline bool ca::isBold(const ColorEntry* base) const { - return (b.t == CO_DFT) && base[b.u+0+(b.v?BASE_COLORS:0)].bold - || (b.t == CO_SYS) && base[b.u+2+(b.v?BASE_COLORS:0)].bold; + return (f.t == CO_DFT) && base[f.u+0+(f.v?BASE_COLORS:0)].bold + || (f.t == CO_SYS) && base[f.u+2+(f.v?BASE_COLORS:0)].bold; } #endif // TECOMMON_H
So, to clarify, 1. /trunk/ - bold is fixed 2. /branches/3.5 - the current state is the way we are leaving it This O.K. with everyone?
I understand that technically this isn't a regression, but from an end-user perspective, "some bold" used to work, and now it doesn't. I really think this should be fixed in 3.5.5.
I agree with Alistair. It's quite annoying at the moment.
O.K. perhaps my email wasn't clear... I'm talking about what in the svn kde 3.5 branch today. Not KDE 3.5.4. Perhaps people can apply the 2 patches (#24 and 25) or update their svn copy and then comment on the current state.
> So, to clarify, > 1. /trunk/ - bold is fixed Well, when I said 'fixed', I mean that in trunk text with the bold attribute is always rendered as bold - no matter what the schema says. This will ultimately have to change. As Lars explained to me, this is both incorrect and not ideal because: - Personal preference (Not everyone likes the look of bold text) - Bold text does not look good in some schemas in particular (eg. midnight commander, Linux console) The existing system (assuming the bugs were fixed) is very flexible, but has its own problems. In short - it is complicated from an end-user's perspective and Konsole does not render text as expected 'out of the box'. - The default Konsole scheme gives unexpected results. I had no idea until Lars told me that I could get bold to work as expected by switching to the Xterm schema. - It isn't obvious that the handling of bold text is controlled by the schema, and there is no way to quickly set the handling of bold text for all colours in a schema. My thoughts on how to resolve this issue, looking at it from an end-user's perspective: - Set the default Konsole schema to one which is similar to xterm and gnome-terminal's default (perhaps with some slight colour tweaks eg. make the 'intensive green' less horribly bright). Also look to see if there is anything else we can do to make Konsole's text look nicer out of the box. eg. Make sure that we use the proper Bold version of the font where available for rendering text. - Make it more obvious in the UI that bold text is handled by the schema, and provide an easier way to set the handling of bold text for a particular schema. Checking / unchecking the 'bold' box for every colour in the palette is a painful process. A preview widget is somewhere on my to-do list for the future, and this would help to clarify the connection of bold text handling and schemas.
Hi, sorry to put more discussion on this but for some colors I don't get any change when I set bold, look try this on konsole: echo -e '\033[38;5;24mblue\033[1mbold\033[m' the 'blue' and the 'bold' is the same! But if I try this in the konsole with the patch by Kurt V. Hindenburg I got then different. What is wrong I think that a color with bold attribute need to be different that a color without it.
Fixed in KDE 4.0, still open for KDE 3.5
Closing as FIXED in KDE 4, WONTFIX for KDE 3.5.x
that's a pity. even simple bug will not even be fixed in kde 3.5.x call it dead.
> that's a pity. even simple bug will not even be fixed in kde 3.5.x Actually one part of the bug was fixed, see comment #25. Repeating the steps outlined in the original report summary, I get the expected result (bold text) in KDE 3.5.9. What isn't fixed are the more complex issues described by Lars. Unfortunately there isn't a "HALFFIXED" status so I called it WONTFIX.