Bug 405345 - Impossible to print "bold red". Bold is always printed as intense/light color
Summary: Impossible to print "bold red". Bold is always printed as intense/light color
Status: REOPENED
Alias: None
Product: konsole
Classification: Applications
Component: font (show other bugs)
Version: 18.08.3
Platform: Other Linux
: NOR normal with 60 votes (vote)
Target Milestone: ---
Assignee: Konsole Developer
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-03-11 10:17 UTC by Stefan
Modified: 2021-11-04 07:59 UTC (History)
10 users (show)

See Also:
Latest Commit:
Version Fixed In: 20.12


Attachments
Observed output in konsole (8.63 KB, image/png)
2019-03-11 10:17 UTC, Stefan
Details
Git commit template comments no visible (11.43 KB, image/png)
2020-12-11 11:30 UTC, Axel
Details
The git commit template when I remove the # at the beginning of the line (13.10 KB, image/png)
2020-12-11 11:31 UTC, Axel
Details
git commit template in Konsole 20.08.3 (25.80 KB, image/png)
2020-12-11 12:08 UTC, Axel
Details
konsole colors (12.56 KB, image/png)
2020-12-11 13:16 UTC, tcanabrava
Details
xfce4-terminal 1;31 is the same color as 0;31, but bold. (286.38 KB, image/png)
2020-12-13 11:09 UTC, Stefan
Details
xfce4-terminal 1;31 is the same color as 1;91. (272.60 KB, image/png)
2020-12-13 11:10 UTC, Stefan
Details
ANSI colors in konsole 20.12.0 (47.83 KB, image/png)
2020-12-24 19:00 UTC, Ricardo J. Barberis
Details
ANSI colors in konsole from pulls/revert-no-intense-color branch (69.45 KB, image/png)
2020-12-24 19:01 UTC, Ricardo J. Barberis
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Stefan 2019-03-11 10:17:28 UTC
Created attachment 118711 [details]
Observed output in konsole

SUMMARY
Konsole always prints "bold" as "light" / "intense".  This is the same color as "light red" and "bold light red".  Other Terminals (e.g., Gnome and macOS) have an option "[ ]  Print bold as light color" that you can turn of to actually get a bold red.  In konsole, the option is "[ ] Print light as bold" which is the inverse and IMHO does not make so much sense.

STEPS TO REPRODUCE
1. Configure the color scheme to have different colors for "red" and "red intense"
2. Run the command `echo -e '\e[0;31mRed\n\e[1;31mRed (bold)\n\e[1;91mLight red (bold)\n\e[0;91mLight red\e[0m'`

OBSERVED RESULT
Line 1 are "red"
Lines 2-4 are "red intense"
Lines 1,4 are regular
Lines 2,3 are bold

EXPECTED RESULT
Lines 1-2 are "red"
Lines 3-4 are "red intense"
Lines 1,4 are regular
Lines 2,3 are bold

SOFTWARE/OS VERSIONS
Windows: 
MacOS: 
Linux/KDE Plasma: 
(available in About System)
KDE Plasma Version: 
KDE Frameworks Version: 
Qt Version: 

ADDITIONAL INFORMATION
Comment 1 Egmont Koblinger 2019-03-11 12:51:51 UTC
+1

To give a bit more context:

The SGR 1 escape sequence, output by e.g.
  echo -e '\e[1mfoobar'
is defined in ECMA-48 § 8.3.117 as "bold or increased intensity".

The most frequent interpretation by graphical terminal emulators is "both: bold and increased intensity".

With 256-color and later in many terminal emulators true color support emerging, and still no unambiguous "bold" on the rise, this approach no longer really makes sense.

Certain color schemes, most notably Solarized requires that the colors remain unchanged, that is, this escape sequence means "bold" only.

GNOME Terminal 3.28 + VTE 0.52 added a new config option "Show bold text in bright colors", toggling whether this particular escape sequence does "both" (when enabled, the old behavior) or "bold only" (when disabled, the new behavior).

GNOME Terminal 3.32 + VTE 0.56, to be released today, flips its default to "bold only" (disabled state of the checkbox).

See https://bugzilla.gnome.org/show_bug.cgi?id=762247 for the GNOME Terminal discussion, and a few comments about the expected consequences.

(Note that in case of VTE, the color is only ever brightened if it was switched to using the legacy SGR 30 .. 37 escape sequences (combined with SGR 1), and never if it was received using the 256-color capable new escape sequences SGR 38:5:0 .. 38:5:7.)

The Kitty terminal emulator strictly only enables "bold" on this escape sequence, and cannot switch to the bright counterpart. That is, its behavior is the same as GNOME Terminal's brand new default. See https://github.com/kovidgoyal/kitty/issues/197.

Also note that with black background, "bold" and "increased intensity" both work towards making the text more prominently stand out. With white background, however, these two concepts work against each other. Bold stands out more, while increased intensity blends more with the background hence is harder to read. The literal meaning of the word "bold", plus the "faint" attribute which is the opposite of this one, along with the fact that dark background was the dominant when this standard was created, also suggests that "bold" is probably the better one to go with. See more thoughts on this at https://bugzilla.gnome.org/show_bug.cgi?id=791596.

Now that we have 16 million colors, and no standalone "bold" flag, we (at least Kitty and GNOME Terminals – I have no contact with macOS Terminal.app guys) believe that terminal emulation should be pushed to the direction when the current mess is cleaned up, and this ambiguous flag continues to live on with "bold only" meaning. It would be lovely if Konsole joined us, too.

> In konsole, the option is "[ ] Print light as bold" which is the inverse
> and IMHO does not make so much sense.

I fully agree.
Comment 2 Nate Graham 2019-03-16 23:41:00 UTC
Fixed just a few days ago in the upcoming KDE Applications 19.04.0. :)
Comment 3 Stefan 2019-03-17 09:21:17 UTC
Awesome! Thank you! :-)
Comment 4 Mariusz Glebocki 2019-03-17 14:33:26 UTC
Neither master nor 19.04 has it fixed.
Comment 5 Nate Graham 2019-03-17 14:37:05 UTC
Oh sorry, I thought this was fixed by your fix for https://cgit.kde.org/konsole.git/commit/?id=41693fe9ee263f8f2281852a740ee52d55f003ef, which fixed the issues with bold text for me.
Comment 6 Stefan 2020-11-16 07:36:35 UTC
Is there any progress or can I help with fixing this?
Comment 7 Stefan 2020-11-16 07:50:40 UTC
The practical impact of this issue is that it makes base16 color schemes unable/harder to use.  

In base16, the "intense" colors are usually some gray tones used for status bars, gutters, or other interface elements.  If you then want to print something in "bold red" it will end up being printed as "bold gray", for example.
Comment 8 Bug Janitor Service 2020-11-27 11:58:12 UTC
A possibly relevant merge request was started @ https://invent.kde.org/utilities/konsole/-/merge_requests/282
Comment 9 Kurt Hindenburg 2020-12-01 03:19:37 UTC
Git commit 270d6ea3247bb41a51535129e4b1c8eef51cf316 by Kurt Hindenburg, on behalf of Carlos Alves.
Committed on 01/12/2020 at 03:19.
Pushed by hindenburg into branch 'master'.

Fix bold character color paint

Konsole was painting 'bold' character as 'faint bold' character.
FIXED-IN: 20.12

M  +1    -7    src/Screen.cpp

https://invent.kde.org/utilities/konsole/commit/270d6ea3247bb41a51535129e4b1c8eef51cf316
Comment 10 Kurt Hindenburg 2020-12-01 03:27:35 UTC
Git commit 82806a2c129f8fa4b21be25b4108eecd8d460625 by Kurt Hindenburg, on behalf of Carlos Alves.
Committed on 01/12/2020 at 03:25.
Pushed by hindenburg into branch 'release/20.12'.

Fix bold character color paint

Konsole was painting 'bold' character as 'faint bold' character.
FIXED-IN: 20.12
(cherry picked from commit 270d6ea3247bb41a51535129e4b1c8eef51cf316)

M  +1    -7    src/Screen.cpp

https://invent.kde.org/utilities/konsole/commit/82806a2c129f8fa4b21be25b4108eecd8d460625
Comment 11 einbert-xeride 2020-12-11 07:05:24 UTC
Is there anyway to keep using old behavior that bold texts are always printed with intense colors? Seems that there's no way to use intense colors for bold texts, and intense colors are no longer used in konsole 20.12.0.
Comment 12 nl6720 2020-12-11 10:36:19 UTC
Please provide a way to change this back!
Some of us rely on "bold" changing the color intensity, just like it does in the TTY.
Comment 13 Axel 2020-12-11 11:30:53 UTC
Created attachment 133999 [details]
Git commit template comments no visible

I'm using the nano-syntax-highlighting package in Arch Linux and the git commit template's colors are broken
Comment 14 Axel 2020-12-11 11:31:41 UTC
Created attachment 134000 [details]
The git commit template when I remove the # at the beginning of the line
Comment 15 tcanabrava 2020-12-11 12:00:56 UTC
Axel, can you provide us the correct colors that this is supposed to look?
Comment 16 Axel 2020-12-11 12:08:20 UTC
Created attachment 134002 [details]
git commit template in Konsole 20.08.3

This is the same colors for Konsole 20.08.3.
Comment 17 Stefan 2020-12-11 13:01:16 UTC
The following command should print all four combinations of (normal, bold) x (normal, faint):

echo -e '\e[0;31mRed\n\e[1;31mRed (bold)\n\e[1;91mLight red (bold)\n\e[0;91mLight red\e[0m'
Comment 18 tcanabrava 2020-12-11 13:16:31 UTC
Created attachment 134003 [details]
konsole colors

Looks right to me.
Comment 19 Magnus Boman 2020-12-11 17:26:25 UTC
Like some others have commented, please add a setting to revert to the old behaviour. Should I make a new issue about this? For now I'll just revert the commit in my local build.
Comment 20 Antonio Russo 2020-12-12 21:53:55 UTC
It was never impossible to print bold red:

echo -e '\e[0;38;2;255;0;0mred \e[1mboldred \e[0m normal'

The present patch (270d6ea32) is essentially equivalent to setting all the intensive colors to the same color as the normal ones.  (Note that the 90-97 character codes used here as an example are not standardized---see https://www.ecma-international.org/publications/files/ECMA-ST/Ecma-048.pdf or https://en.wikipedia.org/wiki/ANSI_escape_code .  We interpret these codes on a best-guess basis.)

Please see https://bugs.kde.org/show_bug.cgi?id=430311 .  I am preparing a patch there that:

- fixes the light color themes (as mentioned here they have reversed intensive semantics);
- uses bold fonts unconditionally for RGB and 256-color spaces (there is no intensive color meaning when a specific color is mentioned as here); and
- again allows for intensive colors to be used.

This avoids breaking decades-old expectations without impeding the development of modern terminal color schemes (use RGB for those).
Comment 21 Stefan 2020-12-12 22:09:10 UTC
But this

echo -e '\e[0;38;2;255;0;0mred \e[1mboldred \e[0m normal'

does not print the same red as

echo -e '\e[0;31mRed\n\e[1;31mRed (bold)\e[0m'

and you cannot use RGB colors in all terminals.

If you use a bas16 colorscheme and "bright" colors are various gray tones, then \e1;31m should still print the bold variant of 31 (red) and not a gray.
Comment 22 Antonio Russo 2020-12-12 22:35:24 UTC
If you want the two following reds to be the same:

echo -e '\e[0;31mRed\n\e[1;31mRed (bold)\e[0m'

then set those two red colors to be the same in the configuration: right click->Edit current profile->appearance->color scheme & font->edit-> change whichever intense color to be the same as the normal one.

I, as well as the other people here who were startled this morning with un-configureable and different behavior, do not want my intense text to have the same color as my non-intense text.  It is (was) just a simple configuration option! :)

> If you use a bas16 colorscheme and "bright" colors are various gray tones, then \e1;31m should still print the bold variant of 31 (red) and not a gray.

I'm not sure I understand this comment.  31 will be whatever color you define it to be in Konsole---which will by default be some red variant.  Did echo -e '\e1;31m text' ever come out gray for you?
Comment 23 Antonio Russo 2020-12-13 04:10:58 UTC
Stefan, what application is using an "intense or bold" font to describe gutters, and expects the colors to be entirely different ("grey tones" entirely unrelated to the normal color)?  I have never seen anything like that, and I cannot help but think we should not be breaking many other applications that use the ANSI specification more to the letter.

I think the actual bug you want is to be able to set the 90-97 colors differently than the intensive colors---is that correct? You mentioned these ANSI codes earlier?
Comment 24 Stefan 2020-12-13 11:08:50 UTC
The idea of base16 (https://github.com/chriskempson/base16) is to carefully design the first 16 ansi colors so that they can be used by various tools for interface coloring and highlighting, e.g. by vim or bat and delta.  The benefit of this is that you can emulate "true colors" in termainsl that don't suport that and that many tools can easily share the same color scheme by just referencing the first 16 ansi colors.

Most terminals I know (Konsole, gnome-terminal, xfce4-terminal, Apple Terminal, iTerm2) support accessing the intense colors via the 90s range and googling "ansi colors" indicates that this is so common that you can rely on this feature in practicse.

Base16 relies on that and uses the 30s range for coloring and the 90s range for gray tones for the interface.

Some terminals print 1;31 as "bright bold red" by default, some print 1;31 as "bold red".  Most of them (excluding Konsole) have an option like "Intensify bold colors"  which toggles between both modes.  I think that this might also be a good solution to fix this issue in Konsole. :)

I attached two example screenshots from xfce4-terminal.
Comment 25 Stefan 2020-12-13 11:09:50 UTC
Created attachment 134041 [details]
xfce4-terminal 1;31 is the same color as 0;31, but bold.
Comment 26 Stefan 2020-12-13 11:10:21 UTC
Created attachment 134042 [details]
xfce4-terminal 1;31 is the same color as 1;91.
Comment 27 Antonio Russo 2020-12-14 06:16:01 UTC
I've got a partial patch that adds back such an option.  It needs more testing, but it is tentatively working:

https://invent.kde.org/utilities/konsole/-/merge_requests/299
Comment 28 Antonio Russo 2020-12-19 19:57:44 UTC
The commit in question has been reverted, but my MR, https://invent.kde.org/utilities/konsole/-/merge_requests/299 , should implement this feature request.

I'd appreciate feedback and testing from interested parties.
Comment 29 Stefan 2020-12-20 19:28:16 UTC
I’d like to try it but I haven’t done any KDE dev yet and have not found an easy guide on how to compile Konsole.  Could you please point me to some docs?
Comment 30 Antonio Russo 2020-12-20 21:47:43 UTC
Hello Stefan!  konsole is actually very easy to build, as long as you have all the dependencies (and there's the rub).  If you're on a Debian testing, you *can* easily get them with

sudo apt-get build-dep konsole

(I'm sure there are similar mechanisms on other distributions, I just don't know them).
However: older releases may not have sufficiently up-to-date dependencies.  You can move forward here, you'll just run into errors later on.  You definitely need cmake 3.13, QT 5.12, and KF5 frameworks 5.68 (or later).

# Get the source

git clone https://invent.kde.org/aerusso/konsole.git -b pulls/revert-no-intense-color
cd konsole

At this point, I will tell you to do whatever due diligence you feel is appropriate to validate that what you've downloaded is safe.

# Next, configure the source:

cmake .

If you run into errors here, you will need to read them and figure out what else needs to be installed.  

# Compile the code!

Here, -j8 tells make to use 8 threads, making it compile ~8x faster (if you have that many cores).

make -j8

# Run it:

./bin/konsole

# Bugs that are not related to my change:

There's a new toolbar that I cannot figure out how to disable.  It also might not go away when you go back to your old version of konsole (!!!).  To get rid of it, find any konsoleui.rc files (probably in ~/.local/share/konsole/konsoleui.rc or ~/.local/share/kxmlgui5/konsole/konsoleui.rc), and delete them.

# What to find:

Edit current profile -> Appearance -> Color scheme & font -> Use bright color for intense text

Un-select that, and apply the change.
Comment 31 Ricardo J. Barberis 2020-12-24 18:47:34 UTC
Antonio, your patch fixes my problems too:

- yellows started looking orange for example
- mc (midnight commander) doesn't show directories as white but greyish
- mcedit doesn't show tabs and trailing spaces and the cursor disapears

With you patch applied everything goes back to normal for me, so thanks!
Comment 32 Ricardo J. Barberis 2020-12-24 19:00:24 UTC
Created attachment 134315 [details]
ANSI colors in konsole 20.12.0

This is right now (frameworks 5.77.0, plasma-desktop 5.20.4, konsole 20.12.0, qt5-5.15.2)
Comment 33 Ricardo J. Barberis 2020-12-24 19:01:50 UTC
Created attachment 134316 [details]
ANSI colors in konsole from pulls/revert-no-intense-color branch

This one is with Antonio's branch
Comment 34 Stefan 2021-01-03 09:54:33 UTC
Antonio,

I finally had the time to compile Konsole from your branch.
Initially I did not find the new option - I expected it to be at the same place as the existing "Draw intense text in bold font" option.

Making it part of the color scheme itself has some benefits though, since theme authors can activate the option for base16 themes directly in the "*.colorscheme" files (or can't they?).

Anyhow, once activated, it works as expected. Thank you! :)
Comment 35 Ricardo J. Barberis 2021-03-17 16:21:10 UTC
I believe this issue can be closed, the bug seems to have been resolved for all the parties' satisfaction.

I'm not closing it in case some use case got left behind :)
Comment 36 Antonio Russo 2021-03-17 21:42:17 UTC
The MR I opened [1] has not been merged---it's still marked as draft, and there are serious design issues with it as it currently stands (it increases technical debt in an part of the code base that needs to be very fast).

I have not had a chance to redo the patchset.  I'd also like to understand the performance impact for this patch (and more generally, for many of the new features being added).  I also cannot say that this is a high priority for me to work on.

Please don't close this bug unless you have confirmed that someone else's patch has been merged, or you are making an executive decision that Konsole will not support the feature requested here.

[1] https://invent.kde.org/utilities/konsole/-/merge_requests/299
Comment 37 Ricardo J. Barberis 2021-03-17 22:05:10 UTC
Was the original change reverted then?

Because the last few versions have been working fine for me and I didn't notice your marge request was still open.

But if there's more use cases to contemplate, that your patch addresses then yes, let's keep this issue open.

(BTW, I'm not an official KDE developer and I'm in no position to make an executive decision about this or other issues, sorry if it seemd that way).
Comment 38 Stefan 2021-11-04 07:59:01 UTC
What’s the status of this issue?  I’ve been using a self-compiled patched version konsole during the last year while I was waiting for this feature to be released. :)

However, konsole  21.08.0 still doesn't have the new *Use bright colors for intense text* option.