GNOME Bugzilla – Bug 767115
support for SGR 53 (overline)
Last modified: 2017-12-11 21:37:48 UTC
If konsole will implement this [see https://bugs.kde.org/show_bug.cgi?id=362171], we should consider supporting it too.
Three similar feature requests, 1 bit left in VteCellAttr :P
Just FTR, the konsole patch was committed.
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??
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.
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 :)
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.)
(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.
+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! :-)
(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...
(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.
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.
Submitted. Will improve on vertical positioning if someone complains. :)