Agreed. The only thing that VS-15 is supposed to do is give the emoji a "text presentation", which the spec suggests as "black & white". And every example they show of a text presentation is exactly the same width as the emoji presentation.
Changing a character's width from wide to narrow after it has already been output is fraught with problems for a terminal. Imagine trying to write a "narrow" text presentation emoji in the bottom right corner of the screen. You'd think it should fit, but the emoji is received before the VS-15 selector, and that doesn't fit, so the terminal is forced to wrap the text, triggering a scroll of the entire page. By the time the VS-15 arrives, there's no way to undo all of that.
And for another example, try using IRM (insert replace mode) to insert a text presentation emoji in the middle of some existing text. If it was really narrow, you'd expect it to insert enough space for just one character, but it actually inserts two spaces, only occupying one of them, and then leaving an unexpected gap. And the more of these "narrow" characters you insert, the bigger the gap becomes.
VS-16 changing a text presentation character from narrow to wide doesn't share these problems. And that behaviour is supported by the spec text, which says that emoji should generally have a square aspect ratio. And at one time the East Asian Width spec specifically mentioned VS-16 making narrow characters wide (but said nothing about VS-15 making wide characters narrow).
This was also an option on many "Glass TTY" terminals - it was called the margin bell - and even some modern terminal emulators still have that option. The exact semantics vary, but it's usually triggered when entering content around 8 characters from the right margin.
> "ANSI" is what people call it when they are working from paltry and incomplete samizdat doco of how this stuff works
People just use "ANSI" as a shorthand for ANSI X3.64-1979. And that was the standard that DEC used for their VT100+ range of terminals, which in turn became the de facto standard from which most modern terminal emulators are derived. If you read the DEC documentation, you'll find many references to "ANSI standard", "ANSI controls", "ANSI colors", etc. I don't think this is because they were ignorant of the subject matter, considering that they were members of the committee that produced that standard.
And ECMA-48 is essentially just the European equivalent of ANSI X3.64, and was developed in parallel. But obviously an American company like DEC or Microsoft would more likely be working from the American version of the standard rather than the European one.
FYI, there are a few terminals that can set the window size in pixels (with `CSI 4 t`). And it's also worth mentioning that there were already terminal emulators back in the 1980s that supported in-band resize notifications (lookup `VTEEWR` - Enable Window Event Reports).
The author mentions problems with flow control, but I'm fairly certain I got that working in MAME. If I remember correctly, you need to enable XON/XOFF in the VT102 configuration (it's one of the bits you can toggle on the SET-UP B page), and also enable it in MAME's Machine Configuration menu.
Also make sure your modem settings in MAME match the settings configured on the VT102. I have them both set to 19200 baud 8N1. I've just done a quick test now, and I can definitely make it through tests 1 and 2 in vttest without the output getting corrupted.
I should also mention that I've got the RS232 device set to null_modem (which is hooked up to a socat instance via MAME's bitbanger feature), rather than the pty configuration that they're using. I'm not sure if that could make a difference to the way the flow control works.
They have a working VT240 which supports the Sixel, ReGIS, and Tektronix graphics protocols. They also have partially working VK100, which is a bit like a VT100 with some graphics support (I think just ReGIS). They don't have a working VT125 as far as I know.
Smooth scrolling on the VT100 was 6 lines per second, but on later terminals you could adjust the speed to a certain degree, as much as 18 lines per second on the level 5 terminals. It's possible you'd still hate it even at that speed, but I wouldn't right it off completely just because you disliked the VT100 implementation.
On later DEC terminals you could also set left and right margins (lookup DECSLRM). They didn't support smooth scrolling when those margins were enabled, but I don't see why a modern terminal emulator couldn't handle that.
IANAL, but the UK's copyright laws appear to me to have many of the same restrictions as the DMCA when it comes to circumventing copyright protection measures. And it wouldn't surprise me to find other countries had passed similar laws.
Changing a character's width from wide to narrow after it has already been output is fraught with problems for a terminal. Imagine trying to write a "narrow" text presentation emoji in the bottom right corner of the screen. You'd think it should fit, but the emoji is received before the VS-15 selector, and that doesn't fit, so the terminal is forced to wrap the text, triggering a scroll of the entire page. By the time the VS-15 arrives, there's no way to undo all of that.
And for another example, try using IRM (insert replace mode) to insert a text presentation emoji in the middle of some existing text. If it was really narrow, you'd expect it to insert enough space for just one character, but it actually inserts two spaces, only occupying one of them, and then leaving an unexpected gap. And the more of these "narrow" characters you insert, the bigger the gap becomes.
VS-16 changing a text presentation character from narrow to wide doesn't share these problems. And that behaviour is supported by the spec text, which says that emoji should generally have a square aspect ratio. And at one time the East Asian Width spec specifically mentioned VS-16 making narrow characters wide (but said nothing about VS-15 making wide characters narrow).