Bug 233065 - konsole fails to draw bright colors in screen when TERM is set to xterm-256colors
Summary: konsole fails to draw bright colors in screen when TERM is set to xterm-256co...
Status: RESOLVED DUPLICATE of bug 274603
Alias: None
Product: konsole
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Debian testing Unspecified
: NOR normal
Target Milestone: ---
Assignee: Konsole Developer
URL:
Keywords:
: 194056 (view as bug list)
Depends on:
Blocks:
 
Reported: 2010-04-02 13:46 UTC by Eckhart Wörner
Modified: 2012-07-07 14:34 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Eckhart Wörner 2010-04-02 13:46:37 UTC
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
Comment 1 Daniel Douglas 2010-07-27 11:40:06 UTC
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
Comment 2 Jekyll Wu 2011-08-05 19:04:41 UTC
*** Bug 194056 has been marked as a duplicate of this bug. ***
Comment 3 Jekyll Wu 2011-10-07 14:34:12 UTC
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 ***
Comment 4 Bernhard Frauendienst 2012-07-07 14:34:14 UTC
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.