> 5 jan. 2023 kl. 03:06 skrev Doug Ewell via Unicode <[email protected]>: > > Mark E. Shoulson replied to Kent Karlsson: > >>> It is, however, a while ago since the last update to ECMA-48, and >>> that shows. I’ve compiled a proposed update for the text styling part >>> of ECMA-48: >>> https://github.com/kent-karlsson/control/blob/main/ecma-48-style-modernisation-2022.pdf >> >> Actually not necessarily a bad idea, at least at first browsing, but >> it's kind of out of scope for Unicode, isn't it? It sounds like an >> update to ECMA-48 (which isn't part of Unicode), and they're the >> people you'd have to convince. > > Actually, Kent's document does include updates and clarifications that are > specific to Unicode. So there is certainly something for readers of this list. > > 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. > > 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: > > 1. Clarifications to existing specifications and usage are fine. > > 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.
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. 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). > 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. > Restricting platforms, for example, from implementing "bold" with zero color > change, (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.) 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? > or from implementing "italic" or "oblique" at an angle outside the range > 8°–12°, Sometimes, and that goes for other implementations than those implementing ECMA-48 as well, a default 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. > or attempting to forbid certain characters beyond what Unicode recommends, 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). > 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. > > 4. Tables that compare existing and proposed ECMA-48 mechanisms, and call > attention to the changes, need to be included. ”Noted.” (As the standard committee parlance goes; meaning ”I will think about it”.) > 5. A table of contents and index, and perhaps a glossary, are badly needed > for a document anywhere near this size. ”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.) Kind regards /Kent K > > -- > Doug Ewell, CC, ALB | Lakewood, CO, US | ewellic.org > >
