GNOME Bugzilla – Bug 791596
Thoughts about faint (SGR 2)
Last modified: 2021-06-10 15:28:26 UTC
ECMA-48 says: SGR 1 bold or increased intensity SGR 2 faint, decreased intensity or second colour SGR 22 normal colour or normal intensity (neither bold nor faint) ITU-T Recommendation T.416 says: SGR 1 Bold or increased intensity SGR 2 Faint or decreased intensity SGR 22 Normal intensity (neither bold nor faint) (We often call SGR 2 "dim" or "half" in our code.) Neither of them state explicitly, but the wording, and the common SGR code for turning them off implicitly suggests to me that most likely SGR 1 and 2 were meant to be mutually exclusive. That's not the case in VTE's current implementation, and not in xterm or konsole either, as you can see e.g. in the output of perf/256test.sh. With the introduction of the 256-color palette, it became clear that SGR 1 should mean bold and is not meant to tamper with the color (at least for the extended color codes). True color support obviously further strenghtened this. In bug 762247 we made yet another step to get closer to this state: a new API allows to turn off SGR 1's increased intensity even for the legacy first 8 color codes, making it strictly bold only and never to alter the color. At the current state of things and direction we're going, the faint attribute (or at least its current interpretation) just doesn't fit this picture. It's an odd one that uses a hardcoded formula to compute the exact RGB color, not settable individually via API or OSC 4-like codes. Furthermore, the formula (copied exactly from xterm) just multiplies each color channel by 2/3. With white-on-black color schemes it's somewhat okay, with black-on-white the default black color isn't made any fainter. Konsole's color editing dialog presents a 3x10 table: foreground, background and the standard 8 color slots, and for each of them "Color", "Intense color" and "Faint color". This is way too much for me, and in the opposite direction that I'd like to move. Interestingly, enabling both SGR 1 & 2 result in the original color, just in bold. Maybe that's konsole's way of achieving what we introduced that new API for? --- Following the existing pattern, and the desire that color should be separated from other attributes, I believe the most reasonable thing would be for SGR 2 to mean an even thinner font than the default, and indeed be mutually exclusive with SGR 1. Setting PANGO_WEIGHT_THIN doesn't do anything for me. Apparently it relies on having such a font weight being installed on the system, and all the monospace fonts I have ship regular and bold weights only. If we go this way, it'll only work for a very few users who set up such a font with at least 3 different weights, e.g. http://input.fontbureau.com/ . Or we could do something analogous to our former "faux bold" feature: "faux thin". We'd render the glyph on a temporary canvas (before downscaling), shift by some amount (probably less than 1px, that is, less than PANGO_SCALE), "AND" the bits, and then downscale by PANGO_SCALE. It might look terrible, I don't know. --- Another, simpler to implement approach could be to revise the formula used in mangling the color: let's say, move the foreground color 1/3 of the way towards the background (this wouldn't even change the result on black background), or something similar along these lines. This could probably provide a similar visual experience to a thinner font with the original color. This still wouldn't solve the philosophical problem though: in presence of 256 and even 16M colors, there shouldn't be another attribute for changing the color only. But we could say that this is the best we could reasonably come up with in order to emulate the look of a thinner font. After all, with antialiasing and thin fonts, we might speak about not mangling the colors, but chances are when a letter is rendered, none of its pixels will be exactly the desired color. (And then still make this property mutually exclusive to bold or not??)
> let's say, move the foreground color 1/3 of the way towards the background So here's the thing I've just realized. "bold" obviously makes the text more prominent, catch your attention. So does "increased intensity" on a dark background. But "increased intensity" over a light background? – not necessarily. Here the brighter colors are often harder to read than their basic counterparts. The core of the confusion on light background: Does increased/decreased intensity mean a color that itself (regardless of the context, the background) lighter or fainter, i.e. higher or lower R,G,B values respectively (doesn't make too much sense to me), or the opposite: does it mean to stand out more from / blend in more to the background (makes more sense to me)? So perhaps this standard was written with dark background in mind only. Perhaps SGR 1's "intense" interepretation all along these ages of confusion should have meant "further away from the background" instead? [Just as Unicode is written with black-on-white in mind only, see U+263A ☺ *white* smiling face and U+263B ☻ *black* smiling face. Sure no one is expected to make an exception for these glyphs when coloring is applied so that they always stay "white" and "black" respectively.] [Also reminds me of the question we had at some point in high school in maths class when we drew a chessboard on the (black or green?) blackboard using a white chalk: which fields are the black ones and which are the white ones? We figured out it's more intuitive to call the chalk-shaded ones "black" and the ones left out "white", that is, it wasn't the actual physical color that mattered.] An interesting conseqeunce is: If I keep the legacy interpretation of SGR 1: increasing the R,G,B components of the color, and implement the quoted possible new semantics for faint, then on white background these two features which are supposed to have opposite effects actually become pretty much the same: brighten, that is, dim (er, what??) the color. I'd argue that the legacy interpretation of SGR 1's intense is probably the wrong one and my new proposal for faint colors is the right one. Maybe it's an English language dilemma here: what do words like "bright", "light", "increased intensity", "dim", "faint", "decreased intensity" etc. mean over a lighting white background where things can only be made darker to stand out?? (For the record, yup, I'm using my gnome-terminal with white background.)
My guess would that this is all about monochrome CRTs. These can produce brighter or fainter images by increasing/decreasing the intensity of the electron beam as it sweeps along the line, and this visually also produces a wider or smaller dot on the screen. So likely 'increased/decreased intensity' was exactly that, and didn't actually change the font (which pixels are 0 and 1) as in a bold/thin font. (The VT100 Technical Manual has quite a bit about intensity, and a quick look at it seems to support this idea. Although, no VT manual I've looked at (up to VT525!) actually defines SGR 2 as supported…) Now what this means for vte... (In reply to Egmont Koblinger from comment #0) > Neither of them state explicitly, but the wording, and the common SGR code > for turning them off implicitly suggests to me that most likely SGR 1 and 2 > were meant to be mutually exclusive. Yes, that's my understanding also. > Following the existing pattern, and the desire that color should be > separated from other attributes, I believe the most reasonable thing would > be for SGR 2 to mean an even thinner font than the default, and indeed be > mutually exclusive with SGR 1. Interesting idea. > Setting PANGO_WEIGHT_THIN doesn't do anything for me. Apparently it relies > on having such a font weight being installed on the system, and all the > monospace fonts I have ship regular and bold weights only. If we go this > way, it'll only work for a very few users who set up such a font with at > least 3 different weights, e.g. http://input.fontbureau.com/ . Really unfortunate that there isn't a Free font for this :-( > Or we could do something analogous to our former "faux bold" feature: "faux > thin". We'd render the glyph on a temporary canvas (before downscaling), > shift by some amount (probably less than 1px, that is, less than > PANGO_SCALE), "AND" the bits, and then downscale by PANGO_SCALE. It might > look terrible, I don't know. Please NO! :-) (In reply to Egmont Koblinger from comment #1) > So perhaps this standard was written with dark background in mind only. Likely yes.
Maybe the simplest is just to remove faint support :) See also https://github.com/kovidgoyal/kitty/issues/135.
Just came across the concept of "Variable Fonts" (see the first few websearch results, as well as Behdad's tweets [1]). Apparently fonts of continuously adjustable weight (and tons of other parameters) is a thing some large key players of the web have recently started to push for. So probably in the foreseeable future we'll see several such free fonts appearing on Linux systems, and available via GTK / Pango. It might make sense to keep this in mind, and in a couple of years go for a lightweight font when "faint" is requested. Or introduce an optional sub-parameter to "bold", allowing to pick from a wider range, and make "faint" an alias. [1] https://twitter.com/behdadesfahbod
Created attachment 374242 [details] Test script for reverse+bright Another tricky case: If SGR 1 implemented as "bright", or SGR 2 "faint", is combined with SGR 7 "negative image" ... [and let's mention that all terminals I came across swap the foreground and background colors on SGR 7, rather than doing "negative image" as in photography: https://en.wikipedia.org/wiki/Negative_(photography) , see also bug 792501 comment 4; I'm not sure what the ECMA or ITU standards really meant here] ... then which color should be brightened or fainted, the original foreground, or the post-swapping one? The following terminals make the text brighter (that is, the one specified using SGR 40..47): - Linux console - Konsole - Pterm (PuTTY) - Terminology The following terminals make the non-text pixels brighter (that is, the original foreground as per SGR 30..37, which now became the background color): - VTE - xterm - urxvt - mlterm - st - Windows Terminal PuTTY is really interesting when it comes to faint: it faints both colors. Some other terminals of the previously listed ones don't support faint at all. For the rest that do, it goes consistently with bright. The Linux console behavior is understandable from the hardware constraint. It was designed for VGA which has 3 bits for background, 4 bits for foreground and 1 for blink. There's no way to store a "reverse" bit, it has to be resolved prior to hitting the VGA buffer by actually swapping the two colors. So this is the only behavior that can be implemented. The xterm & VTE behavior might originate from monochrome screens where, as previously said, bold/bright meant a stronger cathode ray, making the bright color (now background) even brighter. And as already pointed our regarding dark-on-light color schemes, suffers from the problem that bright and bold begin to work against each other: the letters (unlit pixels) become thinner as their surrounding pixels become bolder. To further complicate, let's introduce the "bold color" user setting. In at least xterm and VTE, it replaces the default foreground color (SGR 0 or 39) with the given color when "bold/bright". Now combine with "negative^Wreverse", the effective background receives this color which definitely makes more sense than the other possibility (the "bold color" is likely close to the "foreground color", so replacing the post-swapping foreground with it could easily result in almost unreadable text). If we were to follow the Linux console approach, and cared about bold + reverse + custom bold color, we'd need to introduce a "custom reverse bold color", hell no. --- I just wanted to make a note of these thoughts somewhere, and this issue (including its followup comments) seemed to be the closest.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/vte/-/issues/2462.