<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="">17 dec. 2021 kl. 01:06 skrev Harriet Riddle via Unicode <<a href="mailto:unicode@corp.unicode.org" class="">unicode@corp.unicode.org</a>>:</div><br class="Apple-interchange-newline"><div class="">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" class="">
<div bgcolor="#FFFFFF" text="#000000" class="">
<div class="moz-cite-prefix">William_J_G Overington via Unicode
wrote:<br class="">
</div>
<blockquote type="cite" cite="mid:43ce7487.27f24.17dc532517e.Webtop.96@btinternet.com" 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=""><p 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
</p>
<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><p 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>.
</p><p 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>.
</p>
</blockquote>
(end of excerpt)<br class=""></div></div></blockquote><div><br class=""></div><div>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 type="cite" class=""><div class=""><div bgcolor="#FFFFFF" text="#000000" class=""><br class="">
<blockquote type="cite" cite="mid:43ce7487.27f24.17dc532517e.Webtop.96@btinternet.com" 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><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><br class=""></div><div><br class=""></div><div><br class=""><blockquote type="cite" class=""><div class=""><div bgcolor="#FFFFFF" text="#000000" class=""><blockquote type="cite" cite="mid:43ce7487.27f24.17dc532517e.Webtop.96@btinternet.com" 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><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><br class=""></div><div><br class=""></div><div><br class=""></div><div><br class=""></div><div>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><br class=""></div><div>/Kent K</div><div><br class=""></div><div><br class=""></div><div>PS</div><div>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" 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><br class=""></div><div><blockquote type="cite" class=""><div class=""><div bgcolor="#FFFFFF" text="#000000" class="">
<blockquote type="cite" cite="mid:43ce7487.27f24.17dc532517e.Webtop.96@btinternet.com" class="">
<br class="">
Could we discuss this please?
<br class="">
<br class="">
William Overington
<br class="">
<br class="">
Thursday 16 December 2021
<br class="">
<br class="">
<br class="">
</blockquote>
<br class="">
</div>
</div></blockquote></div><br class=""></body></html>