<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 9/13/19 11:42 AM, Corentin Jabot
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CA+Om+Sg3kBjL60S_-TJDgjoqXDxe4-SGgKrt91NMiep4nK0TCQ@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div dir="ltr"><br>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Fri, 13 Sep 2019 at
15:57, Niall Douglas <<a
href="mailto:s_sourceforge@nedprod.com"
moz-do-not-send="true">s_sourceforge@nedprod.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">On 13/09/2019 14:36,
Victor Zverovich wrote:<br>
>> Instead of inventing something in the abstract, a
good next step would<br>
>> be to figure out how (in UTF-8 mode) Apple
Terminal, Gnome Terminal,<br>
>> Konsole, and the new Windows Terminal determine how
many terminal<br>
>> display column a string takes. (I'm not
volunteering.)<br>
> <br>
> I'm volunteering to do this since improving handling of
width is already<br>
> on my TODO list for the fmt library.<br>
<br>
I'll be interested in what you come up with on this, as I
don't think<br>
this solvable.<br>
<br>
For example, imagine formatting into a file, and then that
file is<br>
rendered onto a console.<br>
<br>
Another example: imagine formatting into a clipboard, which
on Windows<br>
and POSIX might involve three or four renditions into
differing formats<br>
and encodings. Then the consumer of the clipboard chooses an
unknown one<br>
of those renditions, and reinterprets it in some unknown way
into a<br>
paste into some document.<br>
<br>
Personally speaking, I think the best course is to declare
codepoint or<br>
byte based formatting widths, and draw a line under it.<br>
</blockquote>
<div><br>
</div>
<div>Code-points is even less useful than bytes.</div>
</div>
</div>
</blockquote>
<p>Strongly agreed.</p>
<p>Though we should be clear that we're talking about code units
here, not bytes. The difference matters for the wide character
set which has code units that may be more than one byte.<br>
</p>
<blockquote type="cite"
cite="mid:CA+Om+Sg3kBjL60S_-TJDgjoqXDxe4-SGgKrt91NMiep4nK0TCQ@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div><br>
</div>
<div>Bytes or perceived characters, aka egcs.</div>
</div>
</div>
</blockquote>
<p>Perceived characters would be great if there was a specification
that we could draw from, but alas.</p>
<p>Remember that not all EGCs correspond to visibly perceived
characters. Some are intentionally invisible.<br>
</p>
<p>Tom.<br>
</p>
<blockquote type="cite"
cite="mid:CA+Om+Sg3kBjL60S_-TJDgjoqXDxe4-SGgKrt91NMiep4nK0TCQ@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div>I agree that nothing else has value in the context of the
standard</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<br>
Niall<br>
_______________________________________________<br>
SG16 Unicode mailing list<br>
<a href="mailto:Unicode@isocpp.open-std.org" target="_blank"
moz-do-not-send="true">Unicode@isocpp.open-std.org</a><br>
<a href="http://www.open-std.org/mailman/listinfo/unicode"
rel="noreferrer" target="_blank" moz-do-not-send="true">http://www.open-std.org/mailman/listinfo/unicode</a><br>
</blockquote>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
SG16 Unicode mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Unicode@isocpp.open-std.org">Unicode@isocpp.open-std.org</a>
<a class="moz-txt-link-freetext" href="http://www.open-std.org/mailman/listinfo/unicode">http://www.open-std.org/mailman/listinfo/unicode</a>
</pre>
</blockquote>
<p><br>
</p>
</body>
</html>