Disable bold and bold italic? #135
Comments
|
Why would you want to disable bold fonts terminal wide? If you dont like bold, surely the place to disable bold is in whatever applications are producing the bold styling in the first place? |
|
Bold has decreased legibility and usually is coloured differently from the regular anyway. Having text rendered in bold+colour is unnecessary, it is double styling for one semantic change. What usually happens is that instead of rendering bold, a bright color is rendered (see code 1): But in any event, I prefer not to use bold. Colour differences are plenty for me. |
|
Rendering a bright color instead of bold is an awful kludge left over from the days of hardware terminals that did not support bold text. I have been trying to convince people to stop using that kludge for years. It breaks rendering in terminals with proper support for bold fonts, since applications happily assume that bold means an intense color instead of using the proper SGR code for intense colors. See for example: hishamhm/htop#35 As such, I am afraid I am not interested in implementing an option to turn off bold fonts. That simply means that people who want to write applications that use bold fonts now have no way to be sure that the terminal suports bold fonts or not. People that maintain legacy command line applications need to be prodded to do the right thing and get their software out of the stone ages. |
|
Alright, I hear you. However, would there in practice be anything holding me back from specifiying a regular weight font for the bold setting? (I've tried but can't make it work). |
|
It wont work, because kitty appends :weight=200 for the fontconfig query for bold ofnts, so as to ensure it gets back an actual bold font. You could run from source and simply comment out the line in your copy if you want. |
this reduces the amount of bolded text on the screen (basically only directories will be bold in ls) and explicitly requests bright colors for terminals that don't support bold/bright legacy overlapping, eg: kovidgoyal/kitty#135 (comment) mind you, there are countless other terminal applications that still expect bold and bright to mean the same thing, and are not customizable (colored output from pacman, for example), so we still need the bold/bright overlap in practice, eg: alacritty/alacritty@a81152c note that almost every terminal emulator in existence supports both aixterm and 256-color escape codes, so this shouldn't break anywhere. even the linux virtual console recognizes them, although it doesn't always render them correctly (eg compare \e[92;5 to \e[32;5, which is bright green reverse vs regular green reverse; linux tty will render them both the same color).
|
@kovidgoyal FYI I love to see how much we're on the same page here. We're also about to deprecate "allow bold" in VTE, and have just introduced an option for SGR 1 not to brighten the colors (762247). And while at it, you might also be interested in my thoughts about the faint attribute at 791596. Seems to me it's not implemented in Kitty at all, correct? Perhaps we should also just remove it. |
|
kitty does not implement faint and I have no plans to implement it whatsoever. I agree with Christian that it likely is a holdover from the days of CRTs. |
While this is a valid place to ask to disable bold, the fact is that many application use SGR1 by default. The terminal is the tool which executes SGR1, therefore for users it's an easier one-stop-shop to control it - compared to configuring many applications to disable bold or filing bug reports to the applications. Without doing an official study, my assessment is that SGR1 is by far the most commonly used text attribute. Not sure if more or less than (8) colors, but I think more.
I don't think its origin matters. What matters, IMO, is making users happier without sacrificing standard adherence, and preferably also keeping your own principles.
What do you mean by "proper SGR codes for intense colors"? 256/true colors? or SGR 90+? something else? Also, this htop example is problematic. I don't think there's a clear semantics anywhere on how "intensified black" should look like, and what its relation should be to the default BG color (which is not necessarily one of the terminal's 8 ANSI colors). I do agree that it's somewhat questionable to assume that "intense black" will end up visible. However, as much as htop is popular, I think this example is an exception to using SGR1 rather than being the rule.
These people should not write it as a terminal application. SGR1 is "intense/bold". Applications which use SGR1 should (and generally do) expect it to display in a way which stands out compared to without it. I don't think many applications have specific expectations on how it's being made to stand out (within limits, e.g. they do expect it to fit the same space as normal char). It pretty clear that some users have preferences on how they like SGR1 to look. As noted above, lower resolution might make bold fonts less legible, and same goes if the font doesn't have a bold variant - which results in artificial emboldening which can look bad and/or be less legible. I'm guessing some disabilities may also affect this, or just plain old "me like". A terminal is a major user tool, and SGR1 is used a lot. In my eyes, these and others are valid reasons to want it to look in a specific way from the user's point of view. I'm also quite sure that users who knowingly completely disable the effect of of SGR1 are not going to complain to anyone about text not standing out as its developer intended it to. Whether or not you, as the developer, are willing to implement it is of course your thing, but I don't think there's anything else to it other than your own preference (feel free to prove me wrong). However, considering how frequently SGR1 is being used out there, the relative ease* to implement how SGR1 looks, combined with the ability to make users happier, and preferably without breaking standard adherence, I think that providing control over how SGR1 looks is a win. [*] Of course, nothing is ever simple. It might be easy to allow bold/color/both[/none] for the 8 colors, but more confusing with the default color, and even harder with 256/true colors. But this doesn't contradict the overall notion of this post - it's a valid preference to have, and it's up to you [how much of it] to allow. |
|
Transient user here to offer a couple of my thoughts, and how I ended up here:
I am not here to resurrect this "issue". I have been trying to avoid the "bold" colors for a while since they don't render well on the terminal in OS X. I think the direction of this conversation is technically correct. Just about the only thing I could suggest is a special exception for "bright black" since any application that uses it as a proxy for grey will end up with invisible text. Just be aware that sometimes, and not even just in obscure environments, the only way to access half of the available colors is with SGR1. My solution was to use color 244 from the 256-color palette when 256 colors are available, and continue using "bright black" otherwise. They look just about exactly the same outside of kitty. This should hopefully work everywhere since a terminal which doesn't support 256 colors is also unlikely to use a proper bold. As an addendum, I offer this sh alias to strip control codes from piped input, including color and bold. I hope it proves useful for @clauseggers's situation, or any time that legacy code uses color codes in a way that doesn't render well in a standards-abiding terminal. |
At VTE 762247 comment 29 onwards we got a report of bold light gray not being white anymore. As it turned out, the Linux kernel's "make menuconfig" prints stuff with identical fg and bg colors plus the bold attribute, and expects that to be visible. :-) Any of the 8 basic colors would fail here with Kitty's (and VTE's forthcoming new default) color handling. With "bright black" the issue might be more frequent, or the one you happened to come across, but I don't think it's special.
What I'd love to see emerging, if someone feels passionate to implement it, is a generic escape sequence rewriting layer for such cases, with configurable behavior (rewriting rules taken from a config file), and providing a terminal emulator interface towards the apps running inside (so that text editors and such could still run and also be subject to mangling the colors or attributes). I'm sure many people would love it. I guess script(1) could be a good starting point, with its tty handling preserved, these features added, and logging removed. Alternatively some addon to tmux(1). For Linux and Mac at least, no clue about Windows. Until someone volunteers to do it, scripts like yours are obviously helpful in certain cases. |
|
Come on people, make this a configuration option already... Forcing bold fonts on the user and having no options for enabling any combination of bold and/or bright is kinda crazy. Following the same pedantic logic, why don't you put in some "checks" against it then in the event some redefined the color "red" as green or something?... I could even live with this pedantic default, sure. But for people who would like to use existing software in a satisfactory manner, please add these options already, man. |
|
Is there an escape sequence (in kitty), that does the "switch to brighter colors"? |
|
Is there any update on this yet? This option would be super useful when trying to use the same font everywhere and the font does not have a bold version. I don't see how enabling this option would break anything else, iTerm2 and the default MacOS terminal (former despite being quite a basic terminal) both support this. |
It would break @kovidgoyal 's heart |
How would I go about disabling bold and bold italic? That is to say I would like them the bold to be regular and the bold italic to be italic?
I’m on ArchLinux, and have tried to specify the Bold as
Input Mono Narrow:style=Regular(as perfc-list) and asInput Mono Narrow Regular, but neither work.Perhaps make a setting to disallow bold fonts as in other terminal emulators?
The text was updated successfully, but these errors were encountered: