When I was trying the Solarized theme in Konsole, I found that the output of `ls` command became much less colorful compared to the one run in OSX's buildin terminal app. (See also: https://bugs.kde.org/show_bug.cgi?id=364660) The root cause is that Solarized theme somehow considers those 16 system colors to be not related colors, but Konsole considers colors 8~15 as the intensive style of colors 0~7. Therefore, when Konsole encounters the escape character "\e[1m", Konsole will render the rest of the text in intensive color instead of bold font style. These logic leads to another problem: Both "\e[1;34m" and "\e[94m" will lead to same effect of color style. I think a possible solution is to use "\e[1m" for bold fonts, "\e[9Xm" for intensive color. And I also implemented it at here: https://github.com/cathook/kde-konsole/tree/master (commit diff URL: https://github.com/cathook/kde-konsole/commit/7a1573b3cce1d562b1dc053cb89f8abca2fc7642) Another solution might be to extend the color palette from 30 (3 for foreground, 3 for background, 8 * 3 for normal/intensive/faint system colors) into 54 (3 for foreground, 3 for background, 16 * 3 for normal/intensive/faint system colors).
See the gnome-terminal counterpart of this bug for further information: https://bugzilla.gnome.org/show_bug.cgi?id=774794. The 54 entry approach sounds overkill to me, plus cannot address the situation that this debated auto-brigtening feature only kicks in for the legacy escape sequence; the 256-color escape sequence can also address the same colors but doesn't make them brighter. Also, colors with indices 8-15 currently cannot be further brightened, and I wouldn't introduce this possibility. My proposal is to have a checkbox whether to auto-brighten (legacy stupid behavior, probably required by many apps for their nice, "usual" look) or not (the technically sane behavior, also required for Solarized). This checkbox could even be part of the color scheme, next to the 30 colors in Edit Profile -> Appearance -> Edit, and hence could automatically follow the preferred default state of a particular color scheme.
Then what's your opinion about having a option for whether to use bold font or not. Maybe some users just don't like the bold fonts and want to use normal font weight for all cases.
> Then what's your opinion about having a option for whether to use bold font or not. I have vaguely proposed removing it from gnome-terminal at https://bugzilla.gnome.org/show_bug.cgi?id=762247#c1 (I wanted to link this bugreport previously, I mistakenly linked a duplicate of this), but I don't have a firm opinion about it. I tend to believe that users should configure their apps not to ask to output bold text in that case. Many terminal emulators traditionally have an option to disable bold, and/or an option for a "bold color" which is being used when the default foreground color is made bold. The latter one only makes sense in spirit of the legacy "bold is bright" model; if for the standard 8 palette colors one should be able to specify their bold ahemm bright counterpart, they should probably be able to specify one for the default foreground color too (which is not necessarily the white or black one of the palette). As for entirely disabling bold: The 256-color (let alone truecolor) extension started to clarify that for the ambiguous "\e[1m" the correct meaning should be bold and not bright, since the color has a dedicated escape sequence of its own. (And while at it, "\e[2m" aka faint/dim is also a truly stupid one. A thinner font stroke could make sense instead, although it's not a standard typesetting practice, and its usefulness is highly questionable.) > Maybe some users just don't like the bold fonts and want to use normal font weight > for all cases. If we're talking about users simply not liking it, then what about users who don't like italic, users who don't like underlined text, users who don't like certain colors (or combinations thereof) etc.?? Some terminal emulators provide some options for these, e.g. some can enforce a minimum contrast between the foreground and background color of each cell (by disobeying even explilcit RGB foreground colors if it's too close to the background), and I guess every emulator that supports blinking allows to disable it. And what about users using this font in other apps too where they just as much don't like its bold counterpart?? Maybe they should configure their system globally not to use it (e.g. for GNOME this can probably be done at fontconfig level; not sure about KDE). Pushing even further, I'm wondering: why would someone get rid of this useful way of emphasizing text, rather than picking a different font whose bold variant they also like?? That being said, if a terminal emulator lets you disable bold (or maybe choose a different font for bold), so be it. But then at the very least it should probably offer this for italic too. I just personally don't see too much point in these options and I'm not convinced the terminal emulator is the right place for such hacks. Anyway, your original request and my response to that was more of a technical one, this one is more opinion-based, so Konsole developers' opinion should matter more, not mine. :-)
Created attachment 109261 [details] Patch for adding a checkbox for whether to auto-brighten the bold characters. Thank for your detailed explanation! I also implemented a patch based on your proposal: have a checkbox whether to auto-brighten or not in the schema editor. BTW, am I at the right place for contacting the konsole developer team?
> Patch for adding a checkbox for whether to auto-brighten the bold characters. Do you feel like doing this for gnome-terminal too? (Just kidding :-)) > BTW, am I at the right place for contacting the konsole developer team? Yup, you are. (I'm also wondering how much it's okay for me to chime in, especially before any konsole developer says anything.)
Egmont, your comments are very much appreciated.
It still happening https://invent.kde.org/utilities/konsole/-/issues/7
(In reply to cat.hook31894 from comment #4) > Created attachment 109261 [details] > Patch for adding a checkbox for whether to auto-brighten the bold characters. > > Thank for your detailed explanation! I also implemented a patch based on > your proposal: have a checkbox whether to auto-brighten or not in the schema > editor. > > BTW, am I at the right place for contacting the konsole developer team? Is it possible for this patch to be resubmitted at https://invent.kde.org/utilities/konsole/-/merge_requests/
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!