<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="">8 jan. 2023 kl. 18:46 skrev Sławomir Osipiuk <<a href="mailto:sosipiuk@gmail.com" class="">sosipiuk@gmail.com</a>>:</div><br class="Apple-interchange-newline"><div class=""><div class=""><span class="viv-signature"></span>On Wednesday,
04 January 2023, 19:53:40 (-05:00), Kent Karlsson via Unicode
wrote:<br class=""><br class=""><blockquote style="margin: 0 0 0.80ex; border-left: #0000FF
2px solid; padding-left: 1ex" class=""><p class="MsoNormal" style="font-family:Calibri,
sans-serif;font-size:11pt;line-height:15.5467px;margin-left:0cm;margin-bottom:8pt;margin-right:0cm;margin-top:0cm;"><span style="font-size: 11pt;" class="">The advantage this approach has is that by using a
separate class of characters, no substring of printable characters
(including SP, HT), no substring of printable characters can be confused
with controls for text styling.</span></p><div style="font-family: Calibri, sans-serif; font-size: 11pt; line-height: 15.5467px; margin: 0cm 0cm 8pt;" class=""><span lang="EN-GB" class=""></span><br class="webkit-block-placeholder"></div></blockquote><div class=""><br class=""></div><div class="">I don't
see this as a major concern. IMO, what people want from Unicode styling is
one or both of these things:</div><div class=""><br class=""></div><div class="">1. Extremely compact
styling, made possible by assigning dedicated characters for each
style</div></div></div></blockquote><div><br class=""></div>Well, depending on you ambition, you may have to define very many "dedicated characters for each style”.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><div class="">2. Default-ignorable styling markup that neatly disappears
if it cannot be interpreted, made possible by the existing set of
default-ignorable Unicode characters.</div></div></div></blockquote><div><br class=""></div><div>In an earlier draft (not so widely circulated), I hinted at the possibility of mapping ASCII characters within a control sequence to TAG characters to make the entire sequence ”default ignorable”. But I removed that little hint, since I don’t think it would be a good idea (it would further overload the TAG characters; would not be compatible with ECMA-48; and may prevent future extensions unduly, indeed for SCI and math expressions (that otherwise has nothing to do with ECMA-48) I sometimes use a non-ASCII character after the SCI).</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><div class="">ECMA-48 does
the first not very well, </div></div></div></blockquote><div><br class=""></div><div>I’d say it does it quite well, at least compared with many of the existing alternatives. And in addition, parameters can be used to get quite a lot of formatting specified shortly, and fairly generally, for instance for colours use RGB values.</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><div class="">and the the second not at
all.</div></div></div></blockquote><br class=""></div><div>I did hint at one way of doing that (based on ECMA-48) at one point, as I just mentioned. But I deleted that hint.</div><div><br class=""></div><div>Kind regards</div><div>/Kent K</div><div><br class=""></div></body></html>