Support SGR 53 "overline" #4499
Comments
|
@Tyriar |
|
Apparently, microsoft/terminal#6000 has some info but it's not on https://invisible-island.net/xterm/ctlseqs/ctlseqs.html |
|
FYI, some other terminals that support overline include VTE, Konsole, MLTerm, Contour, WezTerm, MinTTY, RLogin, and wayst. I don't think it was implemented on any of the original DEC terminals, but it was supported by a number of their printers. As for applications, I know I've seen a couple of screenshots demonstrating it's use that were posted by people arguing for the feature in some or other terminal, but I can't remember where. The one example I remember was a kind of status line using overlines to separate it from the rest of the page, which I thought was a neat effect. And if you're looking for the official spec, it's defined in ECMA-48. SGR 53 to turn it on and SGR 55 to turn it off. |
|
@j4james Thanks for the update and the overview regarding support across other TEs. Do you happen to know, if the other TEs also support the other attributes in the 50s realm (framed and encircled)? And what could be meant by the 60s specs with the ideogram notion? Is there any support anywhere? (I am not asking this to water the overline idea, but to get an idea, which other SGR ideas might pop up as an impl candidate soon, mainly to avoid changes to the buffer over and over. Also framed and encircled are prolly much harder to realize on renderer side, as I would expect them to extend on neighboring cells...) @Tyriar We might get into rendering trouble here, as we have very limited space between lines only. This gets esp. interesting for underlines taking more space like double or curly, and how overline in the follow-up row should render then. |
|
We already have some overlapping happening when using double underline. Like double underline exceeding the cell bounds here:
Doesn't seem like that big of a deal if they overlap, we can make overline act like a regular underline where appears at the top of the cell and "dodges" text if needed on the canvas renderers like this:
For dom there's |
Contour interprets framed to mean that each cell with that attribute should have an individual square frame around it, and Terminology interprets encircled in a similar way - each cell has a circle around it (I suspect they might just be mapping to the Unicode enclosed alphanumeric characters though). RLogin draws a border around the entire connected sequence of cells that have the framed attribute, which I think might be closer to the original intent. This is quite fun to play with, because it can be any shape, so drawing a line of spaces around the screen is like digging a tunnel. RLogin also supports encircled, but it's rendered exactly the same way as framed.
RLogin implements 60 and 61 as rendering a border on the right of the cell, and 62 and 63 as a border on the left. Technically those renditions are meant to be dependent on the writing direction, so 60/61 should really be underlines for horizontal text, and only right side lines for vertical text, but I don't think it's a terrible interpretation if you only have one writing direction. We were also toying with the idea of using those renditions in Windows Terminal, because the legacy console APIs already support the concept of "grid lines" on every side of the cell, and we have no way of forwarding those attributes over conpty. For now we just use SGR 53 to represent the top grid line. RLogin also implements SGR 50 as a border along the bottom of the cell (essentially the opposite of overline), but that's definitely not standard. And they support SGR 64 as a thicker strike-through rendition, which I also think is wrong (I'm not certain, but my guess was that it was intended to be something like a CJK emphasis mark). |
Thats also what I would have expected to happen, as single char framing/encircling doesnt seem that useful to me. Still my expectation could be poisoned by newer "markup" ideas and I am totally missing the original idea. At least the fact, that it is specced as SGR attribute and not as an explicit operation mode sequence enclosing a bunch of cells, points into the single-char-interpretation direction. Hmm. About the ideogram SGR attributes (60-64): (Its a bit of a shame, that we still have so much trouble to represent script systems of nearly half of the human population.)
Isnt RLogin quite popular in Japan? Maybe a strikethrough has a different meaning there? I really dont know enough of these script systems to jump to any conclusion. I think @Tyriar knows a bit Korean, but we def. have no one in the dev team with a strong CJK background to make an informed conclusion. In summary for xterm.js - looks like overline should be implemented, not much left to discuss on that one. Not so for the other attributes - they seem to be highly uncertain in their intended meaning and differ a lot in their actual repr in other TEs. |
Yeah, I wouldn't be comfortable implementing these without having more convincing evidence of how they were intended to be used.
On that note, it's worth mentioning that DEC did actually have a couple of sequences for drawing "ruled lines" around a group of cells. That feature is identified in the DA report with the number 43. There's some documentation on the subject here.
I'm not sure, but I know the Windows grid line attributes were originally only supported on CJK versions of the OS, and there's an old KB article that refers to them as "Keisen Ruled Lines" ("keisen" is the Japanese word for "ruled line"). The DEC sequences mentioned above were also documented as being for "Asian languages". And this is just speculation, but I'd imagine these grid lines would be very useful for indicating the writing direction, especially on a terminal screen where you don't have much scope for white space. A grid full of ideographic characters could be read multiple ways, but with vertical grid lines between columns, it's immediately obvious how it should be read. Other divisions could possibly be useful for separating concepts or "paragraphs". If you do a bit of image searching, you can find examples of this sort of thing in written text, e.g. here and here. I've no idea if that's a common thing though.
Yeah, I believe the author is Japanese, so they're more likely to know the intended use of these attributes than I would, but I wouldn't necessarily assume they're correct about everything either.
That was my thinking too. |
WT completed feature request: microsoft/terminal#6000
Original VS Code request: microsoft/vscode#173011
The text was updated successfully, but these errors were encountered: