“plain text styling”…

Sławomir Osipiuk sosipiuk at gmail.com
Thu Jan 12 12:16:40 CST 2023


On Thursday, 12 January 2023, 11:57:42 (-05:00), Kent Karlsson wrote:
> 
> Note that the subject line for this thread has quote marks for that reason.
>

Fair enough. But the point stands that what counts as a special character is decided by context. A "<" is not "plain" when writing HTML, just as ESC is not plain in an ECMA-48-aware context. 

In HTML you must represent "<" as "<" but what if you want to represent ESC literally in ECMA-48? The most likely response is "you can't" or "why would you want that?" but that already presupposes that "<" is more plain than ESC – that wanting to be able to include it is more "legitimate" – and that presupposition is more historical baggage than a solid definition.

I'll concede that, by popular opinion (as Doug just pointed out in another message), the C0s are perceived as less plain-text than the common printable characters. 

> 

> And SS1 would be a no-op? A bit like NULL was intended to be…

>

No, you're thinking of SS0, but even that wouldn't necessarily be a no-op. In the framework provided by EMCA-35 (ISO 2022) there are (up to) four "code pages" for graphic characters: G0, G1, G2, and G3.

SS2 invokes a character from G2, and SS3 from G3.

G1 is typically invoked simply by using the high bit in 8-bit environments, (e.g. the extended part of extended ASCII) so a single-shift would be mostly useless. In 7-bit environments though, invoking from G1 needs locking shifts. Hence my musing that an SS1 would be nice to have if you're dealing in 7 bits only and ECMA-35 is incomplete without it.

> SS2 is ”jump to secondary codepage”, SS3 is ”jump to tertiary codepage”.

SS2 is actually "jump to tertiary" – the wonders of zero-based indexing. The GSM-7 "ESC" functions like what ECMA-48 would call SS1, if it existed there.



More information about the Unicode mailing list