Version: (using KDE 4.1.0) Installed from: Compiled From Sources OS: Linux It would be nice to be able to configure the display of bold/non-bold text in Konsole, as it was configurable in 3.5.9 (and earlier).
You can do this in KDE 4 by editing the .colorscheme files created by the color scheme editor manually (these are saved in $KDEDIR/share/apps/konsole where $KDEDIR is either ~/.kde or ~/.kde4). For each colour entry you can add a "Bold=true|false" entry to specify whether the colour should be drawn in bold or not. I'm not sure whether I will add a facility to do this in the UI.
I tried editing the .colorscheme file, and it seems that the Bold=false line is ignored. Setting Bold=true on colors that would not normally be bold works, but disabling bold does not.
Right. There is no way to force a particular color to always be drawn with a normal weight. In KDE 4 if the terminal program requests to draw text in bold then bold output is produced.
According to ECMA-48, the sequence "ESC [ 1 m" turns on "bold or intensified text". In most terminal emulators I've used, including Konsole in KDE 3.5.9, there exists an option to select whether this sequence will actually use a bold font. I feel that KDE4 should provide the same option, although it does not necessarily have to be present in the UI. This feels like a regression from the behavior of KDE 3.5.9, and I would like to see it fixed, if possible.
I concur with en.ABCD. I liked having the option in KDE 3.5.10. I do not like the bold font that is forced on me in KDE 4.1.2. Robert, I respect your trying to implement the specification. I wish more developers would strictly conform to the standards. However, I would ask that you set Bold=true in the Color[0-7]Intense sections of the colorscheme files that come bundled with Konsole but respect if the user changes that to Bold=false in their own colorschemes. In this case, the spec says "bold or intense." You are making the choice for the user rather than letting the user decide. Even if you don't want to put a knob in the UI for this, respecting Bold=false in the colorscheme file should be a very easy change. Thank you!
en.ABCD and anybody else interested, if Robert doesn't want to fix this, you can fix it yourself by changing TerminalDisplay.cpp line 669 (in KDE 4.1.2) from: bool useBold = style->rendition & RE_BOLD || style->isBold(_colorTable) || font().bold(); to: bool useBold = style->isBold(_colorTable) || font().bold(); Then only ANSI colors that have Bold=true specified in the colorscheme file will actually be displayed in bold. :)
*** This bug has been confirmed by popular vote. ***
Created attachment 27711 [details] allow bold to be disabled
> respect if the user changes that to Bold=false in their own colorschemes. I plan to do this. I have written the code for it as well, I haven't committed it yet though. Your patch doesn't do what it says on the tin though, it reverts to the KDE 3.5 behavior where the RE_BOLD attribute is ignored, which is fine if that is what you prefer but I think the defaults in KDE 4 work better for most users.
If you apply my code change and also change the bundled colorscheme files to say Bold=true for the "Intense" colors, then the result will be that users get bold by default but can switch to the old 3.5 behavior by changing the colorscheme to have Bold=false for the Intense colors. Of course, if you'd like to add a "Bold" checkbox to each of the colors in the grid in the UI, that'd be fantastic.
I support that there be a way to disable bold fonts. This was a top annoyance in my switch to Kubuntu Intrepid (KDE 4.1) a few days ago. And although I consider myself an advanced user, I think the Option deserves to be changeable in the UI. I know that this discussion is not in your realm, but I generally do not understand why KDE4 aims in this bondage-the-user-direction. Professional users don't automatically turn dumb when upgrading to KDE4. So what's this stupid dropping of options out of the UI all about anyways? I too see it as a regression.
> So what's this stupid dropping of options out of the UI all about anyways? Whenever you call a decision stupid, please at least imagine yourself in the decision maker's situation for a moment. In the case of this particular report, consider that: - I need to test and support every control that appears in the UI. The more features are accessible from the UI the more maintenance work there is and I already have quite enough bugs to deal with in KDE 4. In KDE 3 there are an awful lot of UI pieces that are rough around the edges, poorly designed or just don't work at all. In order to improve the overall quality and feel of applications it is necessary to pick and choose the options carefully. - I have (or rather, had) a lot of bug reports from users who couldn't figure their way around the options dialogs in Konsole in KDE 3. Most of this is dealt with through re-organisation rather than removing features but I also have to be careful to add options in such a way that they don't cause usability regressions. I have no vendetta against options or a desire to turn Konsole into 'grandma's terminal' but there are reasons for why the UI is the way it is.
(In reply to comment #12) > I have no vendetta against options or a desire to turn Konsole into 'grandma's > terminal' but there are reasons for why the UI is the way it is. Very well. Then could you at least make it respect the Bold option in the colorscheme file? Again, the only changes necessary are the one I posted in comment #6 and setting Bold=true for the "Intense" colors in the bundled colorscheme files. The lusers will see no difference (intense colors will be bold), but the power users will be able to switch off bold for intense colors by editing the colorscheme files.
Robert, sorry for your anger about my comment. I did not mean to attack you personally, it was not even meant explicitly in respect to Konsole. It's maybe owing to my (well, not only my) impression, that KDE4 is heading towards - as you put it - a whole 'grandma's desktop'. That's why I was shouting about option-dropping, since I haven't had so much to change in config files for long time like when I switched to KDE4 a few days ago. Again, this is not your personal fault, nor does this discussion belong here, so it was my fault to start it off that way. And being a decision maker and software engineer myself I fully understand your point that this whole porting and re-designing is an assfull of work that I, amongst zillions of others, really appreciate.
It's been quite a few months since the last comment. I recently upgraded to KDE 4.2, and was looking forward to certain features in Konsole that 3.5 didn't have. This problem of the user not being able to force non-bold fonts is seriously getting in the way. Thankfully, I still have 3.5, and I'll continue to use it. I know this may seem like a trivial issue, but the bolded display is just horrible with my preferred font. I use mutt as my mail reader, and have some colors set to the "bright" ones. This is triggering Konsole to bold the font. And it's ugly. Now I can simply go and fix it in my .muttrc. But then when I go to my real console (i.e. not a terminal emulator) - and I often do that, the color will be all wrong. The reason I set it it to the bright color(s) for mutt is precisely so that I could use it in a real console. Now even if I fix it in .muttrc, that still leaves lots and lots of other programs - not all of which I'll have fine grain control over. This shouldn't come as a surprise to you, but people do get attached to their terminal app's appearance - especially if they have to use it all the time. I've been using Konsole as my primary emulator since I started using Linux 8 years ago. I really like(d) it compared to the alternatives. So pleaseohpleaseohplease fix this - I don't want to have to use another emulator. I really don't. I think the solution's already been mentioned: Make the default behavior bold for intense colors - at least if the app requests it. But let the user override it. Thanks.
(In reply to comment #15) I'll just add my two cents to Beetle B.'s comment. People who use a terminal emulator enough to care about the fonts are probably not going to care if they have to edit some config files to get the appearance they want. In other words, you don't have to make this option accessible through the GUI if that's too much work. Simply having Konsole respect the "Bold=false" in the colorscheme files would be adequate to close this bug.
> I use mutt as my mail reader, > and have some colors set to the "bright" ones. > This is triggering Konsole to bold the font. That shouldn't happen. It used to be the case in KDE 3 that the 'boldness' of a character depended only on its color but not any more. By default we now just use the font weight requested by the terminal application. The converse is true though - if the application asks for a bold font then it will be drawn with a bright version of the color. The logic at the moment is: .colorscheme Color Entry | Font Style Requested By App | Visual Result 1. Bold=false | Non-Bold | Non-Bold 2. Bold=false | Bold | Bold 3. Bold=true | Non-Bold | Bold 4. Bold=true | Bold | Bold The bug is that the .colorscheme entry file should be a tri-state option (Bold=True, Bold=False, Bold=UseCurrentFormat (ie. use the font style requested by the terminal application)) at the moment if the terminal application asks for bold it will always get bold.
(In reply to comment #17) Respectively, I don't think that's the issue this bug is attempting to address. We want to be able to tell Konsole how to interpret the ANSI SGR code 1: [x] Bright color [ ] Bold font While it is true that Konsole correctly interprets the high-intensity color codes in the 90-109 range, essentially no applications use those codes, since they are not supported in the Linux console. Therefore, applications typically use SGR code 1 to select bright/bold appearance. We would like to be able to tell Konsole whether to interpret code 1 as bright, and also, independently, whether to interpret code 1 as bold. Two check boxes in the UI would do nicely.
(In reply to comment #17) > > I use mutt as my mail reader, > > and have some colors set to the "bright" ones. > > This is triggering Konsole to bold the font. > > That shouldn't happen. It used to be the case in KDE 3 that the 'boldness' of > a character depended only on its color but not any more. By default we now That's what is happening. And if I set the color in my .muttrc not to be bright, it doesn't show up in bold in Konsole. So mutt must be demanding it to be bold if I choose a bright color. But let's not get sidetracked with mutt. It's not the only application that's giving trouble. > .colorscheme Color Entry | Font Style Requested By App | Visual Result > > 1. Bold=false | Non-Bold | Non-Bold > 2. Bold=false | Bold | Bold > 3. Bold=true | Non-Bold | Bold > 4. Bold=true | Bold | Bold > > The bug is that the .colorscheme entry file should be a tri-state option > (Bold=True, Bold=False, Bold=UseCurrentFormat (ie. use the font style requested > by the terminal application)) at the moment if the terminal application asks > for bold it will always get bold. How about just having it such that if their is a bold entry, Konsole will always respect it. If there isn't, then Konsole will do whatever the application requests?
(In reply to comment #0) > Version: (using KDE 4.1.0) > Installed from: Compiled From Sources > OS: Linux > > It would be nice to be able to configure the display of bold/non-bold text in Konsole, as it was configurable in 3.5.9 (and earlier). Now it is KDE 4.3.0 and it is still no official workaround for this bug?
4.3.1 now, and still no workaround it looks like.
Another application that dropped a functionality on me. Do I really have to patch the source code for one line to make konsole like it always has been (and nobody was cmplaining)?
This is a fairly serious usability issue. I use Gentoo, and they're officially dropping KDE 3.x. Pretty soon they're going to remove all 3.x packages from their tree. The 4.x Konsole is not an option for me as long as this issue remains.
4.4.3 and still not solved. I love you Konsole 3.5.10!
4.4.85 have an option like "show embolden text on intense color". should we close this bug?
Well if it is global then it is not the same but sufficient for me. And it really is not what the thread is all about, but partially it solves it. I would not lose it ATM.
(In reply to comment #25) > 4.4.85 have an option like "show embolden text on intense color". > > should we close this bug? I haven't tested it myself, but the bug is that you cannot make "emboldened" text show as a different color *instead* of being in bold. If that box just changes the color without also showing the text in a non-bold font, then it is not a solution to the bug.
(In reply to comment #18) > > We want to be able to tell Konsole how to interpret the ANSI SGR code 1: > [x] Bright color > [ ] Bold font > > We would like to be able to tell Konsole whether to interpret code 1 as bright, > and also, independently, whether to interpret code 1 as bold. Two check boxes > in the UI would do nicely. I think your idea is fine. But using two independent check boxes is a little problematic, because that means 4 possible combinations: 1). bold font 2). bright color 3). bright color + bold font 4). no effect( does this make any sense for actual usage?) Currently Konsole always uses bright color when requested, so the only meaningful missing choice is 1). I have no idea whether that is a popular choice. Implementing your suggestion probably would take much more code than making Konsole respect "Bold=false" in colorscheme. So I think your suggestion is unlikely to be considered and implemented in the near future.
(In reply to comment #27) > I haven't tested it myself, but the bug is that you cannot make "emboldened" > text show as a different color *instead* of being in bold. If that box just > changes the color without also showing the text in a non-bold font, then it is > not a solution to the bug. Well, that option does not influence the color(normal/bright). It only influences the font(normal/bold). If this report is just about "there should be a way to disable bold font", then I think that option suffices. If you really need the flexibility of enabling/disabling bold font on the level of each color, then we still need to support the tri-state of "Bold=..." in colorscheme. Frankly, I'm not sure that kind of flexibility would be that useful. But the good news is it shouldn't take much code according to my experiment.
https://bugs.kde.org/show_bug.cgi?id=168300 A simple patch to respect "Bold=false". But I'm more inclined to just remove this per-color-boldness control becuase there is already the per-profile option "BoldIntense" to enable/disable bold. It has been awhile since my previous comments and no feedback are received. Does that imply this per-color-boldness is no longer relevant? If nobody convices me this per-color-boldness control is still useful, I guess this report will be closed and that per-color-boldness control will be removed.
I'm one of the people who complained - I think there were multiple issues. I honestly don't remember how things were back then. At the moment, there's a choice in the options not to make intense colors appear bold. I think that solved it for me (honestly don't know if that's what solved it or something else).
Yes that change solved it for me too.
OK, another 3 weeks have passed and nobody tries to convince me this per-color-boldness is still useful beside the per-profile-boldness. I will remove this incomplete feature.
According to #33 I'll close this and remove the per-color-boldness.