https://bugs.kde.org/show_bug.cgi?id=405345
Egmont Koblinger <egm...@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |egm...@gmail.com
--- Comment #1 from Egmont Koblinger <egm...@gmail.com> ---
+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.
--
You are receiving this mail because:
You are watching all bug changes.
