<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="">19 dec. 2021 kl. 16:48 skrev William_J_G Overington <<a href="mailto:wjgo_10009@btinternet.com" class="">wjgo_10009@btinternet.com</a>>:</div><br class="Apple-interchange-newline"><div class=""><div class="auto-created-dir-div" dir="auto" style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; unicode-bidi: embed;">Hi<div class=""><div style="margin: 0px;" class=""><br class=""></div><div style="margin: 0px;" class="">><span class="Apple-converted-space"> </span><span style="display: inline !important;" class="">That is also a non-starter. But William is right on one point: The Teletext (Text-TV) control codes do (already!) have a graphical representation. And that is … a SPACE.</span></div><div class=""><br style="white-space: pre-wrap;" class=""></div><div style="margin: 0px;" class="">Um. what exactly are you saying I am right about please?</div><div style="margin: 0px;" class=""><br class=""></div><div style="margin: 0px;" class="">><span class="Apple-converted-space"> </span><span style="display: inline !important;" class=""></span><span style="display: inline !important;" class="">And that is … a SPACE.</span></div><div style="margin: 0px;" class=""><span style="display: inline !important;" class=""><br class=""></span></div><div style="margin: 0px;" class=""><span style="display: inline !important;" class="">Not quite. If in Hold graphics mode, a control character might not be displayed as a space.</span></div></div></div></div></blockquote><div><br class=""></div>Yes, that is a detail I glossed over. But whether or not in ”hold graphics mode”, mapping to a SPACE (plus some kind of indication of color change (usually)) or to ”previous G3 char (if any)” (plus some kind of indication of color change (usually)) is a matter of <b class="">conversion</b>, not a matter of control code interpretation (after the conversion).</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class="auto-created-dir-div" dir="auto" style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; unicode-bidi: embed;"><div class=""><div style="margin: 0px;" class=""><span style="display: inline !important;" class=""><br class=""></span></div><div style="margin: 0px;" class=""><span style="display: inline !important;" class=""><span style="display: inline !important;" class=""><a href="https://www.rawles.org.uk/teletext/hold/" class="">https://www.rawles.org.uk/teletext/hold/</a></span><br class=""></span></div><div style="margin: 0px;" class=""><span style="display: inline !important;" class=""><span style="display: inline !important;" class=""><br class=""></span></span></div><div style="margin: 0px;" class=""><span style="display: inline !important;" class=""><span style="display: inline !important;" class="">I used the Hold Graphics character near the start of each line of my Colour Check graphic that was on page 786 of Viewdata in September 1977, which was when I saw it. I do not know for how long it stayed on that Viewdata page. I wonder if it can be recovered from an archive somewhere.</span></span></div><div style="margin: 0px;" class=""><span style="display: inline !important;" class=""><span style="display: inline !important;" class=""><br class=""></span></span></div><div style="margin: 0px;" class=""><span style="display: inline !important;" class=""><span style="display: inline !important;" class="">Basically the design was as if a large block of red colour graphics at upper leftt, a large block of green colour graphics at upper right and a large block of colour graphics at lower middle all overlapped, so that colours of red, green, blue, yellow, white, magenta and cyan all appeared.</span></span></div><div style="margin: 0px;" class=""><span style="display: inline !important;" class=""><span style="display: inline !important;" class=""><br class=""></span></span></div><div style="margin: 0px;" class=""><span style="display: inline !important;" class=""><span style="display: inline !important;" class="">By Hold Graphics mode being in operation, there was no blank cell when the colour changed from red to yellow or from yellow to green, and so on.</span></span></div><div style="margin: 0px;" class=""><span style="display: inline !important;" class=""><span style="display: inline !important;" class=""><br class=""></span></span></div><div style="margin: 0px;" class=""><span style="display: inline !important;" class=""><span style="display: inline !important;" class="">There was a blank area of black of about two or three lines at the top and bottom and black at left and right so that it looked good on the page as a work of art.</span></span></div><div style="margin: 0px;" class=""><span style="display: inline !important;" class=""><span style="display: inline !important;" class=""><br class=""></span></span></div><div style="margin: 0px;" class=""><span style="display: inline !important;" class=""><span style="display: inline !important;" class="">The large blocks of colour were each made of teletext graphics that were the graphic equivalent of a lowercase letter 'e' all of this on a black background, so the large colour blocks were not solid but made up of chunks of colour on a black background. Contiguous graphics were used, so some chunks were one size and some chunks another size.<span class="Apple-converted-space"> </span></span></span></div><div style="margin: 0px;" class=""><span style="display: inline !important;" class=""><span style="display: inline !important;" class=""><br class=""></span></span></div><div style="margin: 0px;" class=""><span style="display: inline !important;" class=""><span style="display: inline !important;" class="">The standards document to which I linked includes a word that I coined, namely telesoftware.</span></span></div><div style="margin: 0px;" class=""><span style="display: inline !important;" class=""><span style="display: inline !important;" class=""><br class=""></span></span></div><div style="margin: 0px;" class=""><span style="display: inline !important;" class=""><span style="display: inline !important;" class="">Regarding my encoding in plane 14 idea.</span></span></div><div style="margin: 0px;" class=""><span style="display: inline !important;" class=""><span style="display: inline !important;" class=""><br class=""></span></span></div><div style="margin: 0px;" class=""><span style="display: inline !important;" class=""><span style="display: inline !important;" class="">><span class="Apple-converted-space"> </span></span></span><span style="white-space: pre-wrap; display: inline !important;" class="">That is also a non-starter.</span></div><div style="margin: 0px;" class=""><br class=""></div><div style="margin: 0px;" class="">Any particular reason for that opinion please?</div></div></div></div></blockquote><div><br class=""></div>Because all of the Teletext control codes are totally absurd/bizarre and should not be encoded in any way whatsoever in Unicode/10646. In addition, newer, and standard, versions of Teletext have in the <b class="">protocol</b> (<i class="">”out of line” with the text</i>) ways of specifying that the text is italic, bold, or has one of a number of colors not covered by the original Teletext implementation. It is a quite complicated conversion (to HTML or ECMA-48-extended) that <b class="">cannot</b> be covered by your approach.</div><div><br class=""></div><div>/Kent K</div><div><br class=""></div><div><br class=""></div><div><blockquote type="cite" class=""><div class=""><div class="auto-created-dir-div" dir="auto" style="caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; unicode-bidi: embed;"><div class=""><div style="margin: 0px;" class="">I suppose that I could incorporate some codes for teletext control codes into The Mariposa System if necessary.</div><div style="margin: 0px;" class=""><br class=""></div><div style="margin: 0px;" class=""><a href="http://www.users.globalnet.co.uk/~ngo/mariposa_novel.htm" class="">http://www.users.globalnet.co.uk/~ngo/mariposa_novel.htm</a><br class=""></div><div style="margin: 0px;" class=""><br class=""></div><div style="margin: 0px;" class=""><a href="http://www.users.globalnet.co.uk/~ngo/" class="">http://www.users.globalnet.co.uk/~ngo/</a><br class=""></div><div style="margin: 0px;" class=""><br class=""></div><div style="margin: 0px;" class="">><span class="Apple-converted-space"> </span><span style="white-space: pre-wrap; display: inline !important;" class="">That is a total, utter, complete, one thousand percent non-starter. Not just for Teletext, but for everything. The quoted section really needs to be deleted. It is an absolutely horrible suggestion, and flies in the face of the design of Unicode and current 10646.</span></div><div class=""><span style="white-space: pre-wrap; display: inline !important;" class=""><br class=""></span></div><div style="margin: 0px;" class=""><span style="white-space: pre-wrap; display: inline !important;" class="">Could you possibly clarify as to which section of what needs to be deleted please?</span></div><div style="margin: 0px;" class=""><br class=""></div><div style="margin: 0px;" class=""><span style="display: inline !important;" class=""><span style="display: inline !important;" class="">Best regards,</span></span></div><div style="margin: 0px;" class=""><span style="display: inline !important;" class=""><span style="display: inline !important;" class=""><br class=""></span></span></div><div style="margin: 0px;" class=""><span style="display: inline !important;" class=""><span style="display: inline !important;" class="">William Overington</span></span></div><div style="margin: 0px;" class=""><span style="display: inline !important;" class=""><span style="display: inline !important;" class=""><br class=""></span></span></div><div style="margin: 0px;" class=""><br class=""></div><br class=""><blockquote style="margin: 0px auto; padding: 0px 2em; border-left-width: 2px; border-left-style: solid; border-left-color: rgb(0, 173, 229); white-space: pre-wrap;" class=""><br class=""><br class="">------ Original Message ------<br class="">From: "Kent Karlsson via Unicode" <<a href="mailto:unicode@corp.unicode.org" class="">unicode@corp.unicode.org</a>><br class="">To: "Harriet Riddle" <<a href="mailto:harjitmoe@outlook.com" class="">harjitmoe@outlook.com</a>><br class="">Cc: "William_J_G Overington" <<a href="mailto:wjgo_10009@btinternet.com" class="">wjgo_10009@btinternet.com</a>>; <a href="mailto:unicode@corp.unicode.org" class="">unicode@corp.unicode.org</a><br class="">Sent: Sunday, 2021 Dec 19 At 11:34<br class="">Subject: Re: Teletext control codes<br class=""><br class=""><br class=""><div class=""><br class=""><blockquote class=""><div class="">17 dec. 2021 kl. 01:06 skrev Harriet Riddle via Unicode <<a href="mailto:unicode@corp.unicode.org" class=""><span class="wt_Email">unicode@corp.unicode.org</span><span class=""></span></a>>:</div><br class="Apple-interchange-newline"><div class="">       <div class="">     <div class="moz-cite-prefix">William_J_G Overington via Unicode       wrote:<br class="">     </div>     <blockquote class="">In       relation to teletext control codes, my opinion is that they need       to be encoded separately from the C0 control range. This would       ensure that in interchange that none of the teletext control codes       is ever misinterpreted as having the basic C0 character meaning.       <br class="">     </blockquote>     <br class="">     What is the "basic C0 character meaning"?<br class="">     <br class="">     In fact, the method of declaring when alternative C0 and C1 sets are     in use is already <i class="">explicitly covered</i> by ISO 10646 in section     13.4, which I excerpt as follows (I've added some explanations in     hard brackets):<br class="">     <blockquote class=""><div style="margin: 0px;" class="">For other C0 or C1 sets, the final octet F shall be obtained         from the International Register of Coded Character         Sets. The identifier sequences for these sets shall be       </div>       <ul class=""><li class="">ESC 02/01 F <i class="">[i.e. 0x1B 0x21 then a byte from 0x40–7E (or             0x30–3F for a private use C0 set)]</i> identifies a C0 set        </li></ul>       <ul class=""><li class="">ESC 02/02 F <i class="">[i.e. 0x1B 0x22 then a byte from 0x40–7E (or             0x30–3F for a private use C1 set)]</i> identifies a C1 set        </li></ul><div style="margin: 0px;" class="">If such an escape sequence appears within a code unit sequence         conforming to ISO/IEC 2022 <i class="">[this strictly speaking includes           e.g. ISO-8859-2, EUC-JP and ISO-2022-JP but not e.g.           Windows-1252, Shift_JIS, EBCDIC or any Unicode           encoding—although this specific provision is applicable to any           ASCII‑ish encoding]</i>, it shall consist         only of the sequences of bit combinations as shown above <i class="">[i.e.           each byte value in the escape sequence shall be emitted as a           single byte of the specified binary value without transcoding]</i>.       </div><div style="margin: 0px;" class="">If such an escape sequence appears within a code unit sequence         conforming to this document <i class="">[i.e. in a Unicode string]</i>,         it shall be padded         in accordance with Clause 12 <i class="">[i.e. in UTF-16 or UTF-32, a           whole code unit shall be emitted for each byte in the escape           sequence, not just the single byte; this has no actual effect           on UTF-8]</i>.       </div>     </blockquote>     (end of excerpt)<br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">That is a total, utter, complete, one thousand percent non-starter. Not just for Teletext, but for everything. The quoted section really needs to be deleted. It is an absolutely horrible suggestion, and flies in the face of the design of Unicode and current 10646.</div><br class=""><br class=""><br class=""><br class=""><blockquote class=""><div class=""><div class=""><br class="">     <blockquote class="">       One possibility is to encode the teletext control characters as a       block of 32 code points in plane 14, without closing up the unused       points. These characters in plane 14 would be displayable       characters and thus not control characters in       non-teletext-emulating systems, each displayed as a glyph       specified in The Unicode Standard as two small capital letters       arranged one above the other, but not overlapping. For example A       above G for Alphanumerics Green.<br class=""></blockquote></div></div></blockquote><div class=""><br class=""></div>That is also a non-starter. But William is right on one point: The Teletext (Text-TV) control codes do (already!) have a graphical representation. And that is … a SPACE.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""><blockquote class=""><div class=""><div class=""><blockquote class="">     </blockquote>          Control "character" is a bit of a wooly term. The term "control <i class="">code</i>"     refers specifically to the category Cc characters (a closed     category), which don't have formal names (although they do have     formal aliases) and mostly have behaviour defined by higher level     protocols rather than by Unicode itself, some of which actually     carry instructions for things other than the text renderer (BEL, for     example). Category Cf, Zl and Zp characters are format effectors,     which are a type of nonprinting character which semantically     constitute part of the text itself and affect only how it's     displayed by triggering (effecting) a particular format behaviour     (line break, RTL override, permitted or forbidden line break,     superscript etc). Some Cc characters from particular C0 or C1 sets     are format effectors (LF for example), but the Cf/Zl/Zp ones are     full-fledged Unicode characters with names and semantics defined by     Unicode itself, not a higher level protocol such as ECMA-48 or the     aforementioned IR-056.<br class="">     <br class="">     The Teletext controls are control <i class="">codes</i>, in existing systems     that incorporate them<br class=""></div></div></blockquote><div class=""><br class=""></div>I’m not sure what that is supposed to explain. I just got confused, it did not appear to make any sense.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">However, there <b class="">are</b> appropriate ways of dealing with (most) Teletext controls in a Unicode context. We discussed that over a year ago. Hint: take your pick: HTML (can handle most of Teletext, with special fonts; <b class="">and that is done for many Teletext pages on a daily basis currently, indeed, minute-by-minute basis, to show them in web pages and smart phone apps</b>) or ECMA-48 (needs some extensions to handle <b class="">all</b> Teletext controls).)</div><div class=""><br class=""></div><div class="">/Kent K</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">PS</div><div class="">Note sure why I have been listed as one of the authors of <a href="https://www.unicode.org/L2/L2021/21235-terminals-supplement.pdf" target="_blank" class="">https://www.unicode.org/L2/L2021/21235-terminals-supplement.pdf</a>. Yes, I have had comments on an earlier version, and I have made suggestions related to it. But I have had no part in writing that document, I have not even been consulted about it. And as you can see from this email, I strongly oppose some of the things suggested there.</div><div class=""><br class=""></div><div class=""><blockquote class=""><div class=""><div class="">     <blockquote class="">       <br class="">       Could we discuss this please?       <br class="">       <br class="">       William Overington       <br class="">       <br class="">       Thursday 16 December 2021       </blockquote></div></div></blockquote></div></blockquote></div></div></div></blockquote></div><br class=""></body></html>