Version: (using KDE 4.3.4) Installed from: Debian testing/unstable Packages This bug has been copied over from http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=531752 ---- In order to enable 256 color support in vim and other console applications the TERM env setting was set to xterm-256color. After this and using the scripts in http://www.frexx.de/xterm-256-notes/ I was able to confirm that the 256 color support was active. Both 256 and 16 color tests passed as expected. Next GNU screen was executed and the tests were repeated. The 256 color test passed successfully with all the colors visible but the 16 color test didn't pass. The bright colors are displayed in bold but not in bright. Also if you are using a font that doesn't support bold colors, there will be no difference between normal and bold/bright colors. This was tested in debian lenny kde3, squeeze and sid kde4 and also kubuntu jaunty kde4 and all displayed the same results. The following screenshot was taken using the font Terminus 8 that doesn't support bold characters. The left panel represents TERM=xterm and the right panel represents TERM=xterm-256color both taken inside screen. http://img223.imageshack.us/img223/3667/wrongcolorskonsolescree.png The same test was also performed on xterm and the problem was not visible. Steps to reproduce: 1-Download the script colortable16.sh from http://www.frexx.de/xterm-256-notes/ 2-Move ~/.screenrc to ~/.screenrc-new (move customizations out of the way) 3-Open a new konsole session 4-Execute: export TERM=xterm 5-Execute: screen 6-Execute: bash colortable16.sh 7-Take a screenshot 8-Detach the screen session 9-Execute: export TERM=xterm-256color 10-Execute: screen -R 11-Take another screenshot 12-Compare the two screenshots, the last one should have the same color on bold and non bold lines
I was able to reproduce this problem by following the spurious advice given in that first link: http://www.frexx.de/xterm-256-notes/ ----- By default, screen is not aware that it is running in a 256 color capable xterm. To make programs in screen recognize this feature, you need to set three things in your ~/.screenrc: # terminfo and termcap for nice 256 color terminal # allow bold colors - necessary for some reason attrcolor b ".I" # tell screen how to set colors. AB = background, AF=foreground termcapinfo xterm 'Co#256:AB=\E[48;5;%dm:AF=\E[38;5;%dm' # erase background with current bg color defbce "on" ----- From what I can tell, none of that has anything to do with 256 color support. The culprit seems to be the attrcolor b ".I" line. According to the screen docs, this means approximately "modify characters marked as bold to have a high-intensity background of the current color." The screen manual may be partially at fault because it gives this same example described as: "Use bright colors for bold text. Most terminal emulators do this already.", while in the previous paragraph the capital "I" is described as a pseudo-attribute which alters the background rather than foreground color. Both resetting the color with "attrcolor b", or using the correct attribute of 'attrcolor b ".i"' makes things show up correctly. I don't have xterm installed but urxvt seems to ignore the attrcolor setting, and if xterm does the same that would explain why the reporter only noticed this in Konsole. Interestingly, my Konsole behaves reverse of what's reported. If TERM=xterm in the Bash environment screen is run from, then bold colors are not intense regardless of attrcolor setting. If TERM=xterm-256color then they show as intense just as they would outside of screen.This may yet be a valid bug as I'm unsure why setting the background color to intense for bold text would negate the intense foreground color. See: http://www.gnu.org/software/screen/manual/screen.html#Attrcolor http://www.gnu.org/software/screen/manual/screen.html#String-Escapes Though I think the bug being discussed is unrelated, this recent mailing list post helped clear things up too: http://lists.kde.org/?l=konsole-devel&m=127811329005415&w=2
*** Bug 194056 has been marked as a duplicate of this bug. ***
Well, by combining the steps mentioned in the original report and the condition mentioned in comment #1, I can kind of reproduce this problem with konsole-2.7.2. But I can't reproduce it with konsole-2.7.999. I think this problem share the same cause with bug #274603, which is already fixed recently. *** This bug has been marked as a duplicate of bug 274603 ***
I can reproduce this bug in konsole 2.8.3 (KDE 4.8.3) when connecting to my FreeBSD (9.0-RELEASE) server. It does NOT happen when connecting to my Gentoo box. The yellow/orange swap (bug 274603) does NOT happen in this case, quite the opposite: inside screen/tmux, both "BOLD" words show in their respective colors, while the both show up as yellow outside screen/tmux (as they do on the Linux box). None of this happens when using urxvt or putty.