<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 1/9/2023 6:13 PM, Mark E. Shoulson
via Unicode wrote:<br>
</div>
<blockquote type="cite"
cite="mid:925a5d79-557d-24ec-1089-9ed0f7952681@shoulson.com">On
1/7/23 06:37, Cristian Secară via Unicode wrote:
<br>
<blockquote type="cite">În data de Thu, 5 Jan 2023 01:53:40 +0100,
Kent Karlsson via Unicode a scris:
<br>
<br>
<blockquote type="cite">More or less regularly there are
(informal) requests on this list for
<br>
encoding (new) control codes or control code sequences for
text
<br>
styling (like bold, italics, text colour, …) also for ”plain
text”.
<br>
</blockquote>
This seems to overlooks that a "plain text" subjected to such
torment can no longer be called "plain".
<br>
</blockquote>
<br>
That was sort of my question at the outset. It doesn't make sense
to call this "plain text" anymore, when it's formatted and
styled. Styling is almost the *definition* of non-plain text.
Unicode is all about plain text, where characters represent glyphs
(or spaces) that represent text. There are some exceptions to
this:
<br>
<br>
</blockquote>
<p>I concur, and my conclusion is that an ECMA-48 data stream is not
plain text. It's just a different type of markup language, where
there's less overlap between the character-subsets for the syntax
characters and the content characters.<br>
</p>
<blockquote type="cite"
cite="mid:925a5d79-557d-24ec-1089-9ed0f7952681@shoulson.com">Mind
you, I think improving and upgrading ECMA-48 is a dandy idea, and
your suggestions for it are as good as any I've seen (which is
faint praise because I haven't seen any, but even from my own
opinion, your ideas are pretty good.) And using it in "text"
files is a thing people have already been doing and will continue
to do, though it is a bit of an abuse of the term "text file."
But I still don't really see how it has to do with Unicode. What
would you have Unicode do? Define a whole set of "formatting
commands" as part of the Unicode standard?
<br>
</blockquote>
A very reasonable question is to ask: what changes if the content
character-subset changes to something that maps Unicode (with a few
exceptions either disallowed or reserved for exclusive use in
syntax). There's certainly an audience here that understands the
question and my have useful feedback.<br>
<blockquote type="cite"
cite="mid:925a5d79-557d-24ec-1089-9ed0f7952681@shoulson.com">
<br>
I think your ideas are good and I'd support them (mostly), just
that this isn't the place that decides such things.
<br>
<br>
</blockquote>
However, as pointed out repeatedly and in different ways, real
progress to where this effort produces something that is actually
useful (not just theoretically usable), comes from involving people
and teams that have an interest in wanting to conform to (and
implement) such an updated standard.<br>
<br>
ECMA-48 originally came out of ECMA, which, like Unicode, is (or
was?) a forum that is based in and supported by industry and
implementers. ECMA's preferred method to launch standards was to get
them started and then pass them off to ISO at some stage of
completeness. <br>
<br>
That approach avoids design efforts being driven by people who have
no stake in the details because they don't or can't be part of the
implementation and rollout of software that provides these new
features to users.<br>
<p>Unicode, we are all agreed, cannot be that forum, because styled
text is not part of the remit, and neither is solving every
possible extension of some other specifications to more fully use
Unicode. So, while interested people can give well-meaning
feedback, we can't really help move this forward - not unless we
happen to also be part of some other organizations.</p>
<p>A./<br>
</p>
<p><br>
</p>
</body>
</html>