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 686043 - italic text colour
italic text colour
Status: RESOLVED OBSOLETE
Product: vte
Classification: Core
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: VTE Maintainers
VTE Maintainers
Depends on:
Blocks:
 
 
Reported: 2012-10-12 15:41 UTC by Christian Persch
Modified: 2021-06-10 14:39 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Christian Persch 2012-10-12 15:41:36 UTC
Since we support defining a text colour for bold text, maybe we should do so for italic (and bold+italic) text, too.
Comment 1 Egmont Koblinger 2014-01-12 11:10:48 UTC
Just wondering about the exact opposite.

My "man man" (man-db 2.6.5) has a section demonstrating the typefaces it uses, showing bold (actually bold) and italic (actually underlined but not italic -- what is ".I" in the manpage for italic eventually becomes "underscore + backspace + character" which is underlined instead). Horrible legacy crap.

If we implement an "Italic color", we should probably have an "Allow italic text" option too (counterpart of the existing "Allow bold text"). And the same for underline (for manpages), strikeout, undercurl, blink...? And to define the color for all their combinations. And an "underlined is italic" option to fix the manpages. And what not.

"Bold color" does quite bad to colorful fullscreen applications (text editors etc.) since you lose a very important property: the actual color of any bold text. I can see it being useful with black and white applications where bold plays an important role, the only one that occurs to me right now is the manpage viewer (which is a total mess anyways). I personally can't imagine someone toggling profiles back and forth for viewing man pages, nor find this a more important use case than e.g. syntax highlighting with proper bold support in editors. And I my opinion the feature of turning bold into a color should reside somewhere in the manpage viewing pipeline (man-db or *roff or less, I don't really care).

I'd rather deprecate and eventually remove the "Allow bold color" and "Bold color" features.

On a slightly related note: The only rationale I can see behind "Allow bold color" is the legacy confusion whether SGR 1 means bold or bright or both. I'd see a point in changing it accordingly to a 3-state config option, taking effect on legacy colors only, whereas on extended colors (where there's no more confusion between brightness and boldness) bold would always mean bold. The g-t config option could also be moved to Compatibility to reduce clutter on the opening tab.
Comment 2 Egmont Koblinger 2014-01-12 11:12:16 UTC
Bug 104968 is the same ticket for underline.
Comment 3 Egmont Koblinger 2014-01-12 11:34:45 UTC
Oh, it's just the bold version of the "default" color defined there, not the bold of any color. Stupid me. Makes a bit more sense now.
Comment 4 GNOME Infrastructure Team 2021-06-10 14:39:04 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/1973.