<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="">(Below)<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">14 dec. 2020 kl. 18:02 skrev Sławomir Osipiuk via Unicode <<a href="mailto:unicode@unicode.org" class="">unicode@unicode.org</a>>:</div></blockquote><div><br class=""></div></div><div><br class=""><blockquote type="cite" class=""><div class=""><div class="">If you or someone else chooses to make a proposal, my own recommendation would be this:<br class=""><br class="">- Assign a new character U+E0002 FORMAT TAG<br class="">- The syntax follows the specification for tagging (chapter 23.9)<br class="">- U+E0002 can be followed by any combination of U+E0062 (bold) U+E0065 (emphatic) U+E0069 (italic) and U+E0079 (underlined) to indicate a span of text with that formatting.<br class="">- U+E0002 U+E007F CANCEL TAG to cancel all formatting<br class="">- Any use of U+E0002 overrides previous formatting (i.e. a "bold" tag alone cancels a previous "italic" tag), so format nesting must be done by combining all desired formats into a single tag.<br class="">- This method should only be used in cases where formatting is required without a higher-level protocol<br class="">- This method should not be used in instances where loss of formatting would greatly alter the meaning of the text or render it incomprehensible.<br class="">- Strikethrough and super/subscript are deliberately omitted for the above reason.<br class=""></div></div></blockquote><div><br class=""></div><div>Now, where did I see something very much like this??? </div><div><br class=""></div><div>…</div><div><br class=""></div><div>…</div><div><br class=""></div><div>Oh yes, ECMA-48. Not exactly the same, but quite close. Indeed very close (especially the ”invisible by default” (”default ignorable”) IF parsed correctly). And… ECMA-48 is already a standard. And… ECMA-48 is already successful, and still <i class="">used every day by very many people</i>. Though it is primarily used in terminal emulators. (Nit: ECMA-48 does have strikethrough… And more. As does HTML/CSS, and when doing ”copy as plain text”, also that formatting disappear.)</div><div><br class=""></div><div>Your U+E0002 FORMAT TAG: ECMA-48  CSI … m</div><div><div>Your U+E0062 (bold): ECMA-48  CSI 1m</div><div class=""><div>Your U+E0065 (emphatic): don’t know what you mean by that</div></div><div>Your U+E0069 (italic): ECMA-48  CSI 3m</div><div>Your U+E0079 (underlined): ECMA-48 CSI 4m</div><div>Your U+E007F CANCEL TAG: ECMA-48  CSI 0m</div><div class=""><br class=""></div><div class="">It is not entirely inconceivable to map all the (otherwise) printable characters used by such control sequences to TAG characters, thus making the ”default ignorable” part of this a bit easier.</div><div class=""><br class=""></div></div><div>Extra nit: Some markdowns (however did that name stick?) allow for strikethrough as well, as -stricken-. Though a bit intuitive, it way too often has an unexpected effect where no strikethrough was intended (try doing ’ls -l’ in your Linux terminal, and paste the result into some place that have that kind of markdown).</div><div><br class=""></div><div>”Math Italic” is a hack for MathML. If done right, MathML would not have needed them either. ”Math Italic” for emphasis in running text (not MathML) only ”works” (sort of, and partially) for English, nearly no other language. Please don’t use the ”Math italic/bold/etc” outside of MathML.</div><div><br class=""></div><div>/Kent Karlsson</div><div><br class=""></div><div>PS</div><div>First edition of ECMA-48 came in 1976. About 44 years ago.</div><div><br class=""></div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div class="">Advantages:<br class="">- Only a single new character needs definition.<br class="">- Uses an existing framework (tags)<br class="">- Formatting is ignorable, implementation is optional<br class="">- A viable method to preserve 95%+ of typical semantic formatting in plain-text<br class="">- IMO a stronger case to have this than either language tags or annotations (argument is to accurately preserve the lot of existing documents that include rudimentary formatting, rather than just invent new features).<br class=""><br class="">Disadvantages:<br class=""><a href="https://xkcd.com/927/" class="">https://xkcd.com/927/</a><br class=""><br class="">Sławomir Osipiuk<br class=""><br class=""><br class=""></div></div></blockquote></div><br class=""></body></html>