<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">12 jan. 2022 kl. 17:53 skrev William_J_G Overington via Unicode <<a href="mailto:unicode@corp.unicode.org" class="">unicode@corp.unicode.org</a>>:</div><br class="Apple-interchange-newline"><div class=""><div class="">In the document<br class=""><br class=""><a href="https://www.unicode.org/L2/L2022/22013-c0-c1-stability.pdf" class="">https://www.unicode.org/L2/L2022/22013-c0-c1-stability.pdf</a><br class=""><br class="">Kent Karlsson writes:<br class=""><br class=""><blockquote type="cite" class="">But there are some character encodings that are “a bit crazy” when it comes to control codes. They override all of C0 (or C1) with something that cannot even be regarded as pure control characters. In particular Teletext ...<br class=""></blockquote><br class="">In my opinion, the control codes of the 1976 teletext specification are a brilliant solution, given the boundary condition that existed at the time.<br class=""></div></div></blockquote><div><br class=""></div>Key: 1976. Then ”all there was” was 7-bit codepages. (7-bit, not 8-bit; the 8th bit was then commonly used for parity, as it still is in the Teletext <i class="">protocol</i>.)</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class="">In order to work, a teletext-equipped television set needed enough solid state memory, to which data could be wriiten and from which data could be read, to store a whole teletext page.<br class=""></div></div></blockquote><div><br class=""></div>Again, 1976. And has been carried on with backwards compatibility until now. However, that is far from making that solution appropriate today, especially not in a Unicode context.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class="">At the time such solid state memory was expensive, so using two kilobytes of memory rather than one kilobyte of memory would have added significant cost to each teletext-equipped television set.<br class=""></div></div></blockquote><div><br class=""></div>Sure. 1976.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class="">So the decision was made to design the specification such that one kilobyte of solid state memory would be sufficient to store a complete teletext page.<br class=""><br class="">I was told that originally the BBC (British Broadcasting Corporation) and the IBA (Independent Broadcasting Authority) had each developed a prototype system of a text-based information system of its own and that the best features of each were included in the agreed common teletext technical specification.<br class=""></div></div></blockquote><div><br class=""></div>I don’t know the historical details, but one precursor to Teletext was apparently ”Videotex” (no ”t” at the end…).</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class="">In an era where personal computing was only starting and computers were mostly in businesses, universities and polytechnics, and mostly in monochrome and just text-based, colourful teletext with its graphics was very futuristic and often on view displaying a multipage (a teletext page on a fixed page number yet such that there were a number of different page displays broadcast in sequence, changing, say, every thirty seconds) in the window display of a shop.<br class=""></div></div></blockquote><div><br class=""></div>That’s fine (1976).</div><div><br class=""></div><div>However, that is far from making that solution appropriate today, especially not in a Unicode context. I would agree that not everything need be turned into HTML, however popular it is (HTML/CSS is great, but needlessly heavy-handed for, say, archiving Teletext pages). Though ECMA-48 is also quite old, it still has solutions for colouring and other styling that 1) are compatible with Unicode, 2) is quite popular (to an extent) in all terminal emulators (but ECMA-48 is not limited to terminal emulators), 3) can handle ”later” extension to Teletext w.r.t. colours and styling (though certain extensions to ECMA-48 would be needed for handling conversion of certain Teletext features, esp. subtitling), 4) are viable also outside of the Teletext protocol (the Teletext triple-function ”controls” have no business outside of the Teletext <i class="">protocol</i>).</div><div><br class=""></div><div>Getting back to what I wrote in <a href="https://www.unicode.org/L2/L2022/22013-c0-c1-stability.pdf:" class="">https://www.unicode.org/L2/L2022/22013-c0-c1-stability.pdf:</a> It is super-highly inappropriate to treat C0/C1 in Unicode as a private-use area, which some have proposed.</div><div><br class=""></div><div>/Kent Karlsson</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class="">William Overington<br class=""><br class="">Wednesday 12 January 2022<br class=""></div></div></blockquote></div><br class=""></body></html>