After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 791596 - Thoughts about faint (SGR 2)
Thoughts about faint (SGR 2)
Status: RESOLVED OBSOLETE
Product: vte
Classification: Core
Component: general
git master
Other Linux
: Normal enhancement
: ---
Assigned To: VTE Maintainers
VTE Maintainers
Depends on:
Blocks:
 
 
Reported: 2017-12-13 21:19 UTC by Egmont Koblinger
Modified: 2021-06-10 15:28 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Test script for reverse+bright (344 bytes, application/x-shellscript)
2019-10-18 21:34 UTC, Egmont Koblinger
Details

Description Egmont Koblinger 2017-12-13 21:19:32 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??)
Comment 1 Egmont Koblinger 2017-12-13 22:11:17 UTC
> 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.)
Comment 2 Christian Persch 2017-12-13 23:30:50 UTC
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.
Comment 3 Egmont Koblinger 2017-12-26 13:05:19 UTC
Maybe the simplest is just to remove faint support :)

See also https://github.com/kovidgoyal/kitty/issues/135.
Comment 4 Egmont Koblinger 2019-06-15 09:51:47 UTC
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
Comment 5 Egmont Koblinger 2019-10-18 21:34:55 UTC
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.
Comment 6 GNOME Infrastructure Team 2021-06-10 15:28:26 UTC
-- 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.