<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="">5 jan. 2023 kl. 03:06 skrev Doug Ewell 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="">Mark E. Shoulson replied to Kent Karlsson:<br class=""><br class=""><blockquote type="cite" class=""><blockquote type="cite" class="">It is, however, a while ago since the last update to ECMA-48, and<br class="">that shows. I’ve compiled a proposed update for the text styling part<br class="">of ECMA-48:<br class=""><a href="https://github.com/kent-karlsson/control/blob/main/ecma-48-style-modernisation-2022.pdf" class="">https://github.com/kent-karlsson/control/blob/main/ecma-48-style-modernisation-2022.pdf</a><br class=""></blockquote><br class="">Actually not necessarily a bad idea, at least at first browsing, but<br class="">it's kind of out of scope for Unicode, isn't it? It sounds like an<br class="">update to ECMA-48 (which isn't part of Unicode), and they're the<br class="">people you'd have to convince.<br class=""></blockquote><br class="">Actually, Kent's document does include updates and clarifications that are specific to Unicode. So there is certainly something for readers of this list.<br class=""><br class="">I agree with Kent's overall assessment that ECMA-48 is the way to go for styling attributes in an environment that strives to remain "plain text," and is far superior, for many reasons, to any proposal to create a completely new mechanism to achieve the same goal.<br class=""><br class="">I have only had time to skim this latest 50-page update, but I would make the same suggestions that I have made before, plus a few others:<br class=""><br class="">1. Clarifications to existing specifications and usage are fine.<br class=""><br class="">2. Completely new inventions, even if they are in the spirit of ECMA-48, should be proposed in separate sections and handled with care. The argument that ECMA-48 is a time-tested standard, widely implemented, loses force in proportion to the amount of emphasis placed on unilaterally creating new stuff.<br class=""></div></div></blockquote><div><br class=""></div>For the most part they are in separate sections, marked as ”new” or ”extended with variants" in the heading; since you made that comment before.</div><div>I did not want to put that in a separate document, since that would destroy the logical ordering and grouping (instead of the alphabetical/numerical ordering used in ECMA-48 5th edition, which makes it all so hard to read).</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class="">3. Deprecated items, items newly noted as "one should try to avoid," and other new restrictions on existing sequences or existing implementations should be proposed in separate sections, and handled with EXTREME care.</div></div></blockquote><div><br class=""></div><blockquote type="cite" class=""><div class=""><div class="">Restricting platforms, for example, from implementing "bold" with zero color change,</div></div></blockquote><div><br class=""></div><div>(I think you meant to write the other way around, i.e. ”as a” instead of ”with zero”; unfortunately some terminal emulators implement bold as a colour change.)</div><div><br class=""></div><div>Bold and colour change are orthogonal. Specifying bold and get a colour change also is at odds with specifying colour as an RGB colour setting. What, for instance, would be the bold colour for RGB 255:140:0?</div><br class=""><blockquote type="cite" class=""><div class=""><div class="">or from implementing "italic" or "oblique" at an angle outside the range 8°–12°,</div></div></blockquote><div><br class=""></div><div>Sometimes, and that goes for other implementations than those implementing ECMA-48 as well, a <b class="">default</b> angle for italics/oblique is used that is annoyingly large (using a run-of-the-mill font, not counting especially artistic ones for special effects). That distracts rather than put emphasis on the emphasized text.</div><br class=""><blockquote type="cite" class=""><div class=""><div class="">or attempting to forbid certain characters beyond what Unicode recommends, </div></div></blockquote><div><br class=""></div>I would need a more detailed comment or comments. This mailing list is not the right place for that (even though this particular comment was in direct reference to Unicode).</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class="">introduces a strong risk that the proposed new standard may be ignored. Think of the concessions that had to be made for Unicode itself to be adopted.<br class=""><br class="">4. Tables that compare existing and proposed ECMA-48 mechanisms, and call attention to the changes, need to be included.<br class=""></div></div></blockquote><div><br class=""></div>”Noted.” (As the standard committee parlance goes; meaning ”I will think about it”.)</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class="">5. A table of contents and index, and perhaps a glossary, are badly needed for a document anywhere near this size.<br class=""></div></div></blockquote><div><br class=""></div>”Noted.” While there is no index as such, there is a summary on pages 46 to 50; almost an index. (A ToC would be easy to generate; but I might put it as an appendix, not up front; it is not a book. I did try to make a logical ordering and grouping; that in contrast to ECMA-48 5th ed., which uses alphabetical ordering, breaking all logical grouping.)</div><div><br class=""></div><div>Kind regards</div><div>/Kent K</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class="">--<br class="">Doug Ewell, CC, ALB | Lakewood, CO, US | <a href="http://ewellic.org" class="">ewellic.org</a><br class=""><br class=""><br class=""></div></div></blockquote></div><br class=""></body></html>