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 767115 - support for SGR 53 (overline)
support for SGR 53 (overline)
Status: RESOLVED FIXED
Product: vte
Classification: Core
Component: general
unspecified
Other Linux
: Normal enhancement
: ---
Assigned To: VTE Maintainers
VTE Maintainers
Depends on:
Blocks:
 
 
Reported: 2016-06-01 16:16 UTC by Christian Persch
Modified: 2017-12-11 21:37 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Overline, v1 (10.65 KB, patch)
2017-12-06 20:17 UTC, Egmont Koblinger
none Details | Review
Overline, v2 (11.20 KB, patch)
2017-12-11 21:26 UTC, Egmont Koblinger
committed Details | Review

Description Christian Persch 2016-06-01 16:16:24 UTC
If konsole will implement this [see https://bugs.kde.org/show_bug.cgi?id=362171], we should consider supporting it too.
Comment 1 Egmont Koblinger 2016-06-01 21:50:26 UTC
Three similar feature requests, 1 bit left in VteCellAttr :P
Comment 2 Christian Persch′ 2016-08-20 19:30:39 UTC
Just FTR, the konsole patch was committed.
Comment 3 Egmont Koblinger 2017-09-19 21:13:53 UTC
After some recent refactoring around the hyperlink feature, we can now grow VteCellAttr as much as we want. Implementing this feature is now a piece of cake.

Would anyone use it though??
Comment 4 Egmont Koblinger 2017-12-05 20:28:31 UTC
Now that I'm working on the curly underline stuff, I'm somewhat tempted to implement this.

On one hand, it's truly simple to add it, so why not.

On the other hand, would anyone use it? For what? And while at it, shouldn't we also add SGR 51/52 framed/encircled and perhaps a few other hardly useful stuff?

Note that konsole is the only emulator I've found that supports overline.
Comment 5 Egmont Koblinger 2017-12-06 19:09:19 UTC
From a comment at https://askubuntu.com/q/528928/398785: Overline could be used in PS1 to produce a thin separator between commands. I quite like this idea :)
Comment 6 Egmont Koblinger 2017-12-06 20:17:52 UTC
Created attachment 365155 [details] [review]
Overline, v1

This patch adds support to SGR 53 (overline) and 55 (off), and shows the overline on the UI.

Goes on top of the v4 patches from bug 721761.

TODO: HTML copy-paste. (Will be tricky if combined with underline and/or strikethrough.)
Comment 7 Christian Persch 2017-12-06 23:06:45 UTC
(In reply to Egmont Koblinger from comment #4)
> On the other hand, would anyone use it? For what? And while at it, shouldn't
> we also add SGR 51/52 framed/encircled and perhaps a few other hardly useful
> stuff?

It seems we already half-do framed ('boxed' in ::draw_cells), it's just hardwired to FALSE and not hooked up to the SGR parser?  Unless there's a use case, we can just keep it that way, IMO.

Encircled can be done by using U+20DD COMBINING ENCLOSING CIRCLE; however we don't seem to get that correct (and it's probably never going to fit for 1-wide cells). Don't really see a use case for this either, so fine with not implementing this until one presents itself.
Comment 8 Christian Persch 2017-12-06 23:16:10 UTC
+m_overline_position = MAX (char_spacing.top + char_ascent / 8 - m_line_thickness, 0);

Why this ascent/8 ? That MAX(., 0) should take care of not drawing outside the cell, and in case we do have space available between top and the ink rect (e.g. cell-height-scale > 1.0) then we should use that for the overline; in fact even put a line_thickness between the overline and the char; like we put a line_thickness between the baseline and the underline.

Otherwise this looks fine, thanks! :-)
Comment 9 Egmont Koblinger 2017-12-07 00:13:41 UTC
(In reply to Christian Persch from comment #8)

> Why this ascent/8 ?

That was pretty ad-hoc (in the spirit of the strikethrough height), it just looked good for me. Will check if it can be improved.

I'm not sure about your idea of putting the overline so much up there.

> in fact even put a line_thickness between the overline and the
> char; like we put a line_thickness between the baseline and the underline.

This is not symmetrical. The analogous to putting the overline above the ascent would be to put the underline below the _descent_ rather than below the _baseline_. Let me see if I find some guidelines about it somewhere...
Comment 10 Egmont Koblinger 2017-12-07 00:18:46 UTC
(In reply to Christian Persch from comment #7)

> Encircled can be done by using U+20DD COMBINING ENCLOSING CIRCLE;

Well, there's also combining underline, combining wavy underline, combining strikethru, combining overline... :)

> Don't really see a use case for this either, so fine with not
> implementing this until one presents itself.

Agreed. Let's skip framed and encircled for now.
Comment 11 Egmont Koblinger 2017-12-11 21:26:43 UTC
Created attachment 365392 [details] [review]
Overline, v2

I've moved the line to the top area of the ascent (it's pretty arbitrary, but at least much simpler than the previous version) and added a FIXME to improve it. It does not go further up to the line spacing area, I believe that'd look ugly.

For HTML, I've just added it next to strikethrough. Interestingly, at least when copying to Gmail in Firefox, it's preserved properly if a cell has a black overline/strikethrough and a red underline at the same time. This is somehow triggered about overline/strikethrough's HTML tag being outside of the text color, and underline being inside, I assume.

It's interesting because looking at HTML's specification about the text-decoration-foo features, I don't think having two decorations of different colors should be possible at all :-)

The combination of strikethrough and overline doesn't seem to appear correctly in HTML, it's so damn low prio that I'd just file a low-prio bug and wouldn't delay this feature now.
Comment 12 Egmont Koblinger 2017-12-11 21:37:48 UTC
Submitted.

Will improve on vertical positioning if someone complains. :)