<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div dir="ltr"><meta http-equiv="content-type" content="text/html; charset=utf-8"><div dir="ltr">(Second reply to same email)</div><div dir="ltr"><br></div><div dir="ltr"><blockquote type="cite">13 jan. 2024 kl. 01:00 skrev Asmus Freytag via Unicode <unicode@corp.unicode.org>:<br></blockquote></div><blockquote type="cite"><div dir="ltr">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<div class="moz-cite-prefix">ECMA-48 is not plain text. It is a form
of markup that uses syntax characters other than those from the
printable ASCII range, but that's about the only distinction.</div></div></blockquote><div><br></div>But that is a key distinction.<div><br></div><div>How do you think of Unicode bidi controls? Plain text or not? They are at the same “level” as ECMA-48 controls!</div><div><br></div><div>Speaking of bidi, that has major security issues very similar to those pointed out for ECMA-48 in a reference given in this thread. For source code and math expressions it must be strongly restricted as pointed out in my two proposals, if at all permitted.<br><div><br><blockquote type="cite"><div dir="ltr">
<div class="moz-cite-prefix">It's different from a true binary
format as well, which would use things like addresses and lengths
to mark the location of text runs and styling info. Instead, like
any other markup, it uses character codes inserted into the data
stream.</div></div></blockquote><div><br></div>Yes, of course.</div><div><br></div><div>(While uncommon as an external representation, the Teletext protocol, in higher implementation levels, does have an addressing based (i.e. out-of-line) representation for some formatting extensions, like additional colours and bold/italics/proportional.)</div><div><br><blockquote type="cite"><div dir="ltr">
<div class="moz-cite-prefix">Now that we have that out of the way,
let's look at the clipboard.</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">The clipboard contains both data and
metadata. By telling a recipient that data is in HTML format it
can be displayed as rich text, instead of as HTML source. The same
is true for rtf or ECMA-48.</div></div></blockquote><div><br></div>While I am not super-knowledgeable about clipboards, I gather that at least one type uses a form of limited HTML as a passe-partout for formatted text, regardless of source and target of copy-paste or the file representations they might support. And that is fine.</div><div><br><blockquote type="cite"><div dir="ltr">
<div class="moz-cite-prefix">The same data can be present in
multiple formats on the clipboard. That's what's behind the
ability to paste "just the text" from a copied section, discarding
the styling.</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Logically, for that to work, either the
sender or the recipient of the clipboard data must understand what
the "just the text" part of the data represents and how to discard
the styling.</div></div></blockquote><div><br></div><div>I gather that it is the sender that fills in some of the available alternatives. For instance it can fill in the HTML slot and the “plain text” slot.</div><div><br></div><div>I don’t think an ECMA-48 slot would be helpful.</div><div><br></div><div>Still it should be, <b>and is already</b>, possible to copy-paste styled text from a terminal emulator to (say) a Word document (neither of which use HTML). (Barring bugs and other imperfections.)</div><br><blockquote type="cite"><div dir="ltr"><div class="moz-cite-prefix">It's been too long, but from what I remember, it was
the sender that had the option of offering multiple formats and
the recipient could pick any that it understood.</div></div></blockquote><div><br></div>Yes. Some applications allow the end user to pick which one.</div><div><br><blockquote type="cite"><div dir="ltr">
<div class="moz-cite-prefix">That's the only logical approach,
because only the sender can be assumed to know the format the data
is in. The receiver could do post-processing only on data formats
already known to it.</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Your ECMA-48 terminal app </div></div></blockquote><div><br></div><div>•I• make/maintain no terminal emulator. I just use some (essentially every work-day).</div><br><blockquote type="cite"><div dir="ltr"><div class="moz-cite-prefix">would
presumably want to offer both the ECMA-48 stream with suitable
metadata defining it as such, as well a plain-text stream, which
discards the styling. </div></div></blockquote><div><br></div>HTML + plain text in the clip board. Many only provide plain text at this time. But that may change.</div><div><br></div><div>/Kent K</div><div><br></div><div><blockquote type="cite"><div dir="ltr">
<div class="moz-cite-prefix">For nested styling syntax I don't know
whether sending applications would perform an "auto close" of any
open styling commands when packaging up the selected text, or
whether that would be done by the receiving app, assuming it
understands the format. The problem how to handle selection at the
boundary of a style run when the style commands themselves are not
visible to the user is the same for markup languages as for
ECMA-48.</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Nothing new to see here, move right
along.</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">A./ <br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">On 1/12/2024 3:26 PM, Marius Spix via
Unicode wrote:<br>
</div>
<blockquote type="cite" cite="mid:20240113002618.575cb477@spixxi">
<pre class="moz-quote-pre" wrap="">Applications like Word or web browsers are able to preserve formatting
by using rich text formats like HTML or RTF in the clipboard. ECMA-48
proposed styling controls work on the plaintext layer, independenlty
from the application, as long the renderer (e. g. Uniscribe or HarfBuzz)
supports them. That would require the clipboard handler of the
operating system to be aware of these sequences.
Am Fri, 12 Jan 2024 22:08:19 +0000
schrieb Doug Ewell <a class="moz-txt-link-rfc2396E" href="mailto:doug@ewellic.org"><doug@ewellic.org></a>:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Eli Zaretskii wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Sorry, I'm probably missing something, because I don't see the
relevance. My point is that copy/paste through the clipboard uses
formats that are not plain text, and encode the styles and typefaces
by using methods that are not compatible with plain text.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">I think Marius will have to address what he meant, as you and I are
talking past each other.
If ECMA-48 markup is part of the plain-text stream, and it is copied
from one app to another in a plain-text Clipboard, then all of the
ECMA-48 sequences should survive the transit.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Alternatively, why is the stated user-experience problem for
ECMA-48 not a problem for Word?
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">I thought I answered that? Or what do you mean by "user
experience"?
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">That question was semi-rhetorical, and was for Marius, who again will
need to respond. I thought he was talking about the human user trying
to select text to be copied, and inadvertently failing to select a
starting or ending ECMA-48 sequence because they are not
human-visible.
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">If pasting between applications, the answer is again clipboard
format that is not plain text. If you copy plain text, the
formatting is lost.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">Wait: are we saying that ECMA-48 sequences like CSI 31m are plain
text, or that they are not?
--
Doug Ewell, CC, ALB | Lakewood, CO, US | ewellic.org
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap=""></pre>
</blockquote>
<p><br>
</p>
</div></blockquote></div></div></div></body></html>