Kent Karlsson wrote: >> 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 do see that individual functions are marked ”new” or ”extended with variants" in the heading, which does help. I was thinking more of putting all the new items together in one top-level section, and all the extended items together in another top-level section, separate from the unchanged or merely clarified items. This is better than not announcing them at all, though. > 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). I didn’t suggest putting them in a separate document, at least not here. That said, I would suggest that you should not necessarily feel constrained to abide by the way ECMA-48 itself is arranged, especially if you aren’t planning to submit this as a formal update to the standard. >> 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.) Yes, I did phrase it backward. > 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? I agree that it is far from ideal if a platform is incapable of true bolding and displays “bold white” as a brighter white (in contrast to “light gray”). And certainly not every color can be made into “fake bold” with a brighter color. It’s a hack, to be sure. We will have to disagree as to whether such a platform should be forced to not support CSI 1m at all. > 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. Some fonts are designed poorly. I don’t think this document is the place to make that aesthetic judgment. -- Doug Ewell, CC, ALB | Lakewood, CO, US | ewellic.org
