What's the point?  "it's actually pretty cool" is not enough reason :).  Any application that requires this?

This is a chicken and egg situation; not many modern apps support it, but not having support in a major desktop can't help.

I suppose "completeness" is probably not a good enough reason (or competion, it looks like konsole can do this).
http://markmail.org/message/fbe4naus75j7bbge
+ More googling indicates xterm too  (I'll need to actually try this at home when I get a chance).

It adds a lot of flexibility;
you can miss-use this to have different characters on the top and bottom to 
I quite like the idea of using it to display teletext pages + possibly for double height menubars and such (but maybe I'm just weird!)

I'm pretty sure no apps supported 256 colour terminal emulation, but this was added.


But yes, it's certainly possible I'm the only one with this particular itch :)

If xterm does it, that's reason enough.  Please reopen if that's the case.  Helps if you point me to the exact part of the spec and some test control sequences so I can actually see what this is about.

I verified that xterm supports this by running vttest
http://invisible-island.net/vttest/vttest.html

The display of xterm of this "torture test" looked pretty good too
http://www.inwap.com/pdp10/vt100test.txt
- Looking at this in xterm vs the source is pretty good

Spec
http://vt100.net/docs/vt100-ug/chapter3.html

Reopening as per comment 4 and 5.

vt100test.txt's 'double height' test only shows up as two lines with the same text in double-spacing (on xterm 303) ?

Quite possibly a regression, since seems to work on an earlier version:

# xterm -version
XTerm(278)

Screenshot
http://imgur.com/MYi1rxP

This appears to be a bug in the xterm configure script.

-test "$enable_doublechars" = no && AC_DEFINE(OPT_DEC_CHRSET,0,[Define to 0 to...
+test "$enable_doublechars" = no || AC_DEFINE(OPT_DEC_CHRSET,1,[Define to 1 to...

However even with finally getting OPT_DEC_CHRSET defined to 1 which from looking at the code appears to be the right switch, the rendering still is unchanged and not as it should be wrt. double width/height.

What I see is:

* xterm(306) -font 6x13 (the default): Everything's perfect.
* xterm -font 10x20: More or less okay, plenty of display artifacts that get more or less fixed on mouse highlight.
* xterm -fa Monospace: Doesn't work at all, apparently the rendering part is only implemented with bitmap fonts.
* konsole: Several display problems, and it gets much worse when you try to repaint parts of the screen (highlight with mouse, or drag the scrollbar).
* pterm/putty: Works correctly. (Except for line drawing which might be an independent issue).
* urxvt, st, terminology: No support.

Do we want this feature? I don't think so.

I don't think we need to implement this.

Sorry for re-awakening an old thread.

If we were to implement it, how'd we go about it? I ask it because I'd love to help, but digging into VTE source is a bit intimidating (at least, my first 10 minutes were).

I guess initial support could be just placing a space to the right of the printed character when using double width and outputting spaces when rendering the lower half of double height chars. That much, I guess, I could do more or less right away.

I think it's worth the effort to go for a full implementation, however. It seems we are using increasingly more frequently terminals and text-based UIs, graphs included (speedometer, htop, etc) and having different font sizes would allow richer UIs much easier than dealing with 2x3 graphical blocks (which IS a pain). Right now I have 9 terminal sessions opened on various desktops and I'd love if they were also pretty to look at.

IRCC When I tried double height characters on real terminals it was possible to output just one half of a character, so I'd imagine you don't need to output a space.

It's worth having a look at the VT100 torture test linked above and seeing what that does to generate it's the output in the screenshot above.

Now that I've taken a closer look at this feature in xterm, I like it even less than before.

I thought you could print double sized characters (vertically only or horizontally only or in both directions) anywhere. Nope. This is a property of _lines_. Each physical line can be double-width, and (orthogonally to this) can be double-height upper half or double-height lower half. For double-height characters to be readable, it's your responsibility to print the same thing in two consecutive lines. The escape sequence, wherever is encountered, immediately switches the state of that line and that line only.

There are escape sequences to set double-height top half or bottom half (ESC # 3 and 4), double-width (ESC # 6) or back to single-width (ESC # 5), but there's no dedicated one documented in ctlseqs.txt to go back to single-height. We'd need to investigate which other escape sequences reset this property as a side effect. Actually, http://vt100.net/docs/vt100-ug/chapter3.html says something different which seems to make sense and might be correct.

Double-width line, unlike CJK characters, is a display only property, applied _after_ all the terminal emulation logic was taken care of. Example on a standard 80-column terminal (enter the command without the line break):

echo -e '\e#6Some very long sentence that does not fit in a single line demonstrating how much this feature sucks.'

Output: The first line contains the first 40 characters in double-width: "Some very long sentence that does not fi" and a little bit of the next "t" also appears as an artifact and does not scroll / does not get removed later (at least with my default 6x13 font) (by the way, the letter is cut in half if the window is odd wide). The second line contains the sentence from the 81st character, in single-width: "h this feature sucks." Characters 41 to 80 are invisible.

Widening the window reveals the bits that were cut off, which is pretty unusual from xterm (as it typically loses everything at the right margin when the window is made narrower).

Cursor positioning also goes accordingly, e.g. moving up to a double-width line suddenly visually doubles the x coordinate of the cursor.

Single utilities that "just" print stuff are out of the game since they don't know where printed stuff will become hidden, or where the line will wrap and hence the style set back to the default (or where they have to begin repeating what they just printed for double-height). Ncurses doesn't support this feature. Not too many apps remain that might consider adding it.

Not to even mention that it's theoretically impossible for apps like "tmux" to support it with adjacent panes (the feature would need to be redesigned to go per-character and not per-line), even apps that added support would IMO probably look terrible, and finally I have no clue whatsoever what we should do on rewrap-on-resize (being able to rewrap on resize requires that per-physical-line properties of this kind do not exist).

I personally find this feature utterly broken and useless, absolutely not worth complicating our codebase with.

(In reply to Egmont Koblinger from comment #13)

> double-width, and (orthogonally to this) can be double-height

Oops, I was wrong. Double-height implies double-width. (I wonder why... I guess this is what some ancient hardware terminal supported for reasons long forgotten, and xterm/konsole just copied it.) You cannot have tall narrow characters. Which means that...

(In reply to Stuart Axon from comment #2)

> I quite like the idea of using it to display teletext pages + possibly for
> double height menubars and such (but maybe I'm just weird!)

... even with this feature you wouldn't be able to display teletext pages, nor double height menubars.

It seems, after digging deeper into the VT-420 documentation, that xterm is correctly emulating it - these are attributes that affects the whole line. Someone probably had a couple bits left in the page memory that could be used to half the pixel clock or the character line counter... Any sane use would require them to be a per-character thing, which would not be compatible with DEC terminals anyway.

Oh well...

I guess we'll have to continue with 2x3 blocks and agree with a WONTFIX here.

At least we tried.

(By the way, what do you mean by 2x3 blocks? I don't get that and I'm curious :))

I was referring to the Videotext 2x3 block mosaics which seemingly (/me slaps forehead) are not included in Unicode.

2x2 blocks are in the block elements group (U+2580..U+259F) and you can use 4x4 chars to get a very 8-bit computer font. One can also misuse Braille for that, but the results are really awful.

It seems I have some yak herd shaving (checking the history of why Videotext mosaics aren't in Unicode, since it seems too obvious an addition, and, if the impossible really happened - nobody thought of it until now, write a proposal) to do.

And, while I'm there, I can try to sneak in 4x2 block graphics, which would be cool.

sigh...

To be more specific, it's the 2x3 mosaic graphics defined in ITU T.101 document.

Thanks for this extra info :)

I wish Unicode defined more such glyphs, I even miss the upper eights and right eights counterparts of U+258x (in plenty of scenarios you cannot invert the colors easily, or at all).

In the mean time I'm sorry but I do not have any motivation adding support for glyphs outside of Unicode. (See also bug 787228, a request to get rid of stateful box drawing mode – while I see compatibility issues there and don't see the practical benefits of getting rid of that mode yet, I don't want to walk away further of that goal either. And of course see also bug 729204: Sixel support.)

If these are important for you specifically, maybe you can go with Unicode's Private Use Area, and have some "add-on" fonts like Powerline does.

Just FYI, this was just recently discussed again on the unicode ML, see the thread starting at https://unicode.org/mail-arch/unicode-ml/y2017-m04/0097.html (older discussion also exist). If you're interested to help out: https://unicode.org/mail-arch/unicode-ml/y2017-m04/0191.html .

https://www.unicode.org/L2/L2017/17435-terminals-prop.pdf

(In reply to Egmont Koblinger from comment #14)
> (In reply to Egmont Koblinger from comment #13)
> 
> > double-width, and (orthogonally to this) can be double-height
> 
> Oops, I was wrong. Double-height implies double-width. (I wonder why... I
> guess this is what some ancient hardware terminal supported for reasons long
> forgotten, and xterm/konsole just copied it.) You cannot have tall narrow
> characters.

Not in DEC, no. But Wyse terminals had double-height single-width, using ESC : for the top half and ESC ; for the bottom half (WYDHL). (See WY370 manual, for example). Still affects a property of the line, though.

Actually it's ESC # : and ESC # ; resp.

(In reply to Christian Persch from comment #22)

> Still affects a property of the line, though.

I vote for closing this as WONTFIX; actually I think I'd generally vote for any feature that couldn't theoretically be screen'ed / tmux'ed to automatically get closed as WONTFIX :)

I think a WONTFIX is a bit too harsh, but, for sure, if such a feature is ever implemented, it'd need to be disabled by default. If your terminal wants it too much, it'd be fine for it to enable it to provide an as-close-as possible emulation.

We are already in the imaginary terminal realm anyway - no actual physical terminal knew what to do with Unicode. If we want it, we can decide to bend the rules to suit ourselves, either by never implementing something that existed, or by slightly extending the feature in a specific way.

Okay, let me clarify:

A firm "let's close as WONTFIX" for me for _this particular_ specification that makes certain entire rows double-width and/or double-height.

I'm somewhat open (although not keen) to have something else that does double-sizing on individual characters (more precisely: a cell could contain a half or a quarter (corner) of a letter). But there's no precedence of it, so no one would use it etc.

We could keep this bugreport open for this, but then it will probably remain open for the next couple of decades without anyone working on it. :)

> it'd need to be disabled by default

We don't have compile-time flags for enabling/disabling features. That's just yet another maintenance burden for hardly any benefit. If something is implemented, it is implemented and available.

IIRC the VT220 did work per character, pretty sure we could just get the top or bottom of a character and it didn't end up with the whole line a different size.

I'm remembering back to the late 90s though, so could be wrong (yeah, VT220 was very old by then, but we had a bunch in our college).

I think we could have someone with a real VT-220 to check. I also have the impression I saw a DEC terminal that had tall/wide text on the top left and some normal text to the right, but some of the terminals in that generation supported text-based windowing too and I was using Minitel terminals (that could switch back and forth on the same line) at the same period, so I may have a glitchy memory.

Minitel supports 'double hauteur', 'double largeur' and 'double grandeur' using ESC M/N/O [http://millevaches.hydraule.org/info/minitel/specs/norme.htm] (double height, double width, double size; these escape sequences have different meantings in vte, however). 

And one of the minitel standard documents (well, the only that I could find online) makes me think that you *might* be right that these attributes were per-character, not for the whole line:

* hauteur simple ou double (occupation de 2 matrices 8x10, superposées si la double hauteur est validée)
* largeur esimple ou double (occupation de 2 matrices 8x10, juxtaposées si la double largeur est validée)
* simple ou double taille (occupation de 4 matrices 8x10 si la double taille est validée)

[STUM1 B, partie 2, chapitre 2, page 84] [http://543210.free.fr/TV/stum1b.pdf]

Also relevant here is the videotex standard (ITU-T T.101); I've only had a quick reading which suggests that these attributes were per-character there, too.

In any case, *if* we were to implement this in vte, it certainly only makes sense to implement this as a character attribute, not a line attribute.

I've never seen a technical spec in French :D

Let's mention one more thing when it comes to teletext emulation or double height.

In the past, character cells were often (almost) square shaped. This can be seen in the PDF linked from comment 21 (e.g. Commodore and ZX Spectrum screenshots), teletext web image search results, also the 8x10 mentioned in the previous comment.

Nowadays, with most fonts, charcells are much more of approx. 2:1 ratio.

This, combined with double height, would result in 4:1 ratio for those letters, which is probably not that super easily readable.

---

And, while at it, I'd return to Behdad's comment 1...

Screenshots at http://www.troude.com/pinky/index.html-ssi confirm that double w/h/s are per character, not per line in minitel.

(In reply to Egmont Koblinger from comment #30)
> In the past, character cells were often (almost) square shaped. This can be
> seen in the PDF linked from comment 21 (e.g. Commodore and ZX Spectrum
> screenshots), teletext web image search results, also the 8x10 mentioned in
> the previous comment.
> 
> Nowadays, with most fonts, charcells are much more of approx. 2:1 ratio.
> 
> This, combined with double height, would result in 4:1 ratio for those
> letters, which is probably not that super easily readable.

Naturally, that calls for support of quadruple-width double-height characters :-)

> And, while at it, I'd return to Behdad's comment 1...

Nowadays, double-size would be useful to 'enlarge emoji so I can at least have a small chance to decipher their meaning' ;-)

> Naturally, that calls for support of quadruple-width double-height
> characters :-)

:-)

> Nowadays, double-size would be useful to 'enlarge emoji so I can at least
> have a small chance to decipher their meaning' ;-)

But it'd need tons and tons of changes in plenty of software so that they ask the terminal emulator to display emojis in double size. And would still only work in apps that control the entire screen, rather than produce a stream to stdout. (Or would you trick it to pull the lines apart if there's a double-height glyph somewhere? Suddenly everything gets damn complicated here, and requires enormous amounts of work for marginal benefits.)

For seeing the emojis, I'd rather think about a view-only approach, e.g. a magnifying glass on keypress.

> would result in 4:1 ratio for those letters, which is probably not that 
> super easily readable.

It really depends on the font you are using. Home computers had much more closer to square pixels due to the limitations of NTSC horizontal resolution on TVs. When you see a 2:3 screen in 25x80, which was common in business computers and terminals, you end up with character cells that are more or less twice as tall as they are wide. Terminals such as the HP 2640 had roughly square character cells because they had a wider screen than a TV. If you use a font that closely mimics the VT terminals in 25x80, you'll end up with a 4:1 cell on double height, but most terminal fonts have a more "relaxed" 5:7 look these days. The font I use is more or less 5:6.

I don't think too many programs would like to play with that. Maybe a top/htop/topng-like program would like to do it to show, say, average load in a larger font. I think CDC's SCOPE used three on-screen font sizes to highlight something (but the CDC 6600 console was a completely different beast from anything vte tries to emulate).

(In reply to Ricardo Bánffy from comment #33)

> but most terminal fonts have a more
> "relaxed" 5:7 look these days. The font I use is more or less 5:6.

Really? :)

xterm's traditional default, the "fixed" font is 6x13. Other alternatives it offers by default via its menu are 5x7, 6x10, 7x13, 9x15, 10x20.

I use gnome-terminal with "Monospace Regular 9" which is 7x15. Other Regular monospace fonts available on my system via gnome-terminal's settings, arbitrarily remaining at size 9 (whatever this number means), are: Courier 10 Pitch (7x15), DejaVu Sans (7x15), Fira Code (7x16), FreeMono (7x13), Hack (7x15), Liberation (7x14), Nimbus (7x14), Noto (7x15), Tlwg (7x16), Ubuntu (6x13).

With the exception of some of xterm's choices, these are pretty much around 2:1.

Created attachment 369110 [details]
Sample text, stretched 200% on t axis

Since vte is not bound by the same issues those vintage terminals were, it can do a lot better. Attached is a sample image obtained from one of my terminals, stretched as a bitmap operation to 200% its original vertical size.

I've filed https://gitlab.gnome.org/GNOME/vte/issues/189 for continuing the "2x3 block mosaic" aka "sextant" subthread.

-- 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/1671.