RE: “plain text styling”…

[Doug Ewell]

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