<div dir="ltr">> 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><div>
> display column a string takes. (I'm not volunteering.)</div><div><br></div><div>I'm volunteering to do this since improving handling of width is already on my TODO list for the fmt library.<br></div>
<br>
> Storage implies code unit count. Do people actually use, _with<br>
> Unicode_, fields of storage that are so fixed-width that they need to<br>
> be padded to the full storage width _and_ do they use std::format to<br>
> do so? (I guess anything is possible, but this seems to me like a very<br><div>
> specialized niche use case whose premise is a bad idea.)</div><div><br></div><div>From my experience such uses are extremely rare. As I wrote earlier the main use case for width is visually aligning the text.</div><div><br></div><div>P.S. Henri, thanks for the blog post. It was very insightful and timely.<br></div><div><br></div><div>- Victor<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Sep 11, 2019 at 11:06 PM Henri Sivonen <<a href="mailto:hsivonen@hsivonen.fi">hsivonen@hsivonen.fi</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 Thu, Sep 12, 2019 at 4:08 AM Thiago Macieira <<a href="mailto:thiago@macieira.org" target="_blank">thiago@macieira.org</a>> wrote:<br>
> But I think that we clearly have two distinct uses: a code unit count for<br>
> storage purposes and a cell grid (monospace font) count for alignment<br>
> purposes. Note how maxima and minima are inverted: usually, if you're trying<br>
> to align you need to specify a minimum, but if you're trying to ensure<br>
> something fits a storage, you specify a maximum.<br>
<br>
Having stuff line up on a terminal grid in the Unicode context calls<br>
for East Asian Width (in the mode that resolves ambiguous characters<br>
as narrow). The concept ignores lots of scripts, but many of those<br>
scripts have properties such that combining those scripts with the<br>
notion of having stuff line up on a grid leads to a bad time<br>
regardless of exact definitions.<br>
<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>
Storage implies code unit count. Do people actually use, _with<br>
Unicode_, fields of storage that are so fixed-width that they need to<br>
be padded to the full storage width _and_ do they use std::format to<br>
do so? (I guess anything is possible, but this seems to me like a very<br>
specialized niche use case whose premise is a bad idea.)<br>
<br>
-- <br>
Henri Sivonen<br>
<a href="mailto:hsivonen@hsivonen.fi" target="_blank">hsivonen@hsivonen.fi</a><br>
<a href="https://hsivonen.fi/" rel="noreferrer" target="_blank">https://hsivonen.fi/</a><br>
_______________________________________________<br>
SG16 Unicode mailing list<br>
<a href="mailto:Unicode@isocpp.open-std.org" target="_blank">Unicode@isocpp.open-std.org</a><br>
<a href="http://www.open-std.org/mailman/listinfo/unicode" rel="noreferrer" target="_blank">http://www.open-std.org/mailman/listinfo/unicode</a><br>
</blockquote></div>