<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><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><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>Right, but it’s a markup/protocol at the plain text •level•.<div><br></div><div>That’s why it works for such things as terminal emulators, where all •higher• level markups (like HTML, RTF, …) are non-starters.<div><br></div><div>That is also why I think it would be a good and simple way to style (as external/file format) text that doesn’t need the full power say HTML or Word. That doesn’t mean that the control sequences should be visible to end users, not at all.<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>That, I gather is a common internal representation. One still need to consider that a selection of text often doesn’t coincide with styling boundaries, and one needs to insert styling markers at the beginning of the clip (when cutting/copying) and at the end of the clip when pasting, and if cutting also adjust the styling at the cut.</div><div><br></div><div>But this isn’t specific to this way of styling, it goes for all forms of styling that uses spans in any way or form.</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>Right.</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></blockquote><div><br></div>Yes.</div><div><br><blockquote type="cite"><div dir="ltr">
<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. 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. <br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<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></blockquote><div><br></div>Yes and yes.</div><div><br><blockquote type="cite"><div dir="ltr">
<div class="moz-cite-prefix">Your ECMA-48 terminal app 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>Or convert to a limited form of HTML/CSS, which I gather some systems use as a passe-partout for conveying styled text in the clipboard. This conversation may be a bit imperfect.</div><div><br><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></blockquote><div><br></div>Yes, it is a bit tricky and another reason why these operations are still imperfect.</div><div><br><blockquote type="cite"><div dir="ltr">
<div class="moz-cite-prefix">Nothing new to see here, move right
along.</div></div></blockquote><div><br></div>Just so. W.r.t. cut-and-paste…</div><div><br></div><div>/Kent K</div><div><br></div><div><blockquote type="cite"><div dir="ltr">
<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>