OverStrike control character

[Kent Karlsson]

> 12 juni 2020 kl. 17:12 skrev Doug Ewell via Unicode <unicode at unicode.org>:
> 
> If we're going to get all ECMA-48 about this, there is also CUB (CSI D), which moves the "active presentation position" back one character, or HPB (CSI j), which moves the "active data position" back one character. (Notice that even ECMA-48 understands the difference between presentation and data.)

Note that CUB (and related: CUD, CUF, CUU) moves the cursor position (”active position”) AFTER GCC (if anything has where supported that one), line breaking, bidi (ECMA-48 had its own approach to that) and line/character directions. Note that CUB moves to the left, even for text with vertical lines, it’s a purely ”visual” move. HPB (and related: HPR) moves the cursor position BEFORE (nowadays referred to as ”backing store”) all that, it’s a ”logical” move. (They need to be synched up, moving one will move the other, but ECMA-48 does not give exact details.) Such cursor movement control sequences are not suitable to store in the ”backing store”, but ECMA-48 does not say so explicitly.

And CUB (with the absent parameter defaulted to 1) is what your favorite terminal emulator sends (to the program reading what you type on the keyboard) when you press the left arrow key on the keyboard. 

Maybe arrow keys in terminal emulators should have sent HPB/CNL/CPL/HPR (and have them interpreted as specified) instead of CUB/CUD/CUU/CUF. Sometimes it seems like the CUB/CUF are interpreted as if they were HPB/HPR. However, this is for terminal emulators only. Otherwise, ”window" programs use keystroke events, not bothering with these cursor movement control sequences. But terminal emulators will be with us for quite some time yet!

/Kent K

> Both of these take an optional numeric parameter, so you can back up more than one position if you want.
> 
> So you have those. And if they don't work for you, well, then they don't work. It's no different from adding an overstrike mechanism to Unicode and expecting it to work for everyone, in all editing and displaying contexts, with all fonts and rendering engines, on all platforms.
> 
> This is a very non-Unicode concept and I would suggest re-reading what Ken Whistler and others had to say about it.
> 
> --
> Doug Ewell | Thornton, CO, US | ewellic.org
> 
> 
>