<div dir="ltr"><div>To the best of my knowledge the main use case for width is to align the text when viewed in a terminal or an editor with a monospace font. The second use case is padding the output with &#39;\0&#39;, space, or some other character to satisfy some width requirements. It is somewhat limited in addressing the first use case because, as pointed out by Tom, it&#39;s hard to solve this problem in general (but it&#39;s possibly to have decent approximations), but it works if you restrict your inputs which is what often happens in practice.<br></div><div><br></div><div>&gt; If no vendor feels that their customers would benefit from a field-width
 specifier, then there simply won&#39;t be any implementation of 
field-width, and therefore there will be nothing that needs 
standardizing.</div><div><br></div><div>That is the worst possible option in my opinion because it will create a portability nightmare similar to the one that currently exists with printf extensions.<br></div><div><br></div><div>Cheers,<br></div><div>Victor<br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Sep 11, 2019 at 11:58 AM Arthur O&#39;Dwyer &lt;<a href="mailto:arthur.j.odwyer@gmail.com">arthur.j.odwyer@gmail.com</a>&gt; 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"><div dir="ltr"><div>[cc: Victor Zverovich, as the person most likely to know about use-cases for `fmt`]</div><div><br></div>What is the <i><b>use-case</b></i> for the field-width format specifier?<div><br><div>If it has no use-case, then WG21 should consider not standardizing it.  WG21 could leave the question of what-it-should-do up to individual implementors — via conforming extensions to a standard &lt;format&gt; implementation. If no vendor feels that their customers would benefit from a field-width specifier, then there simply won&#39;t be any implementation of field-width, and therefore there will be nothing that needs standardizing.</div><div><br></div><div>–Arthur</div><div><br></div><div><br></div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Sep 10, 2019 at 11:19 AM Steve Downey via Lib &lt;<a href="mailto:lib@lists.isocpp.org" target="_blank">lib@lists.isocpp.org</a>&gt; 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"><div dir="ltr">Even with monospace fonts you can&#39;t just rely on number of characters once you are beyond ASCII. Han characters are often double wide.<br>This kind of formatting can&#39;t be made to work in the general case, so we&#39;re left with what might be least surprising. Where almost any choice is going to be surprising to someone. Given that, I would prefer that it be stable, and therefore independent of locale. </div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Sep 10, 2019 at 10:36 AM Niall Douglas &lt;<a href="mailto:s_sourceforge@nedprod.com" target="_blank">s_sourceforge@nedprod.com</a>&gt; 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"><br>
&gt; Perhaps it would be helpful to enumerate what we expect to be portable<br>
&gt; uses of field widths.  My personal take is that they are useful to<br>
&gt; specify widths for fields where the content is restricted to members of<br>
&gt; the basic source character set where we already have a guarantee that<br>
&gt; each character can be represented with one code unit. <br>
<br>
Most programmers would use field widths for padding items so they appear<br>
in a grid. They would expect that 𐐗 padded to eight characters yields<br>
seven spaces and 𐐗, not four spaces and 𐐗 (because 𐐗 consumes four<br>
bytes of UTF-8).<br>
<br>
That said, as we have no idea how unicode would get rendered (0, 1, or 4<br>
characters for 𐐗 being the most likely), I cannot improve on your<br>
proposal. The situation sucks, quite frankly.<br>
<br>
Niall<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>
_______________________________________________<br>
Lib mailing list<br>
<a href="mailto:Lib@lists.isocpp.org" target="_blank">Lib@lists.isocpp.org</a><br>
Subscription: <a href="https://lists.isocpp.org/mailman/listinfo.cgi/lib" rel="noreferrer" target="_blank">https://lists.isocpp.org/mailman/listinfo.cgi/lib</a><br>
Link to this post: <a href="http://lists.isocpp.org/lib/2019/09/13533.php" rel="noreferrer" target="_blank">http://lists.isocpp.org/lib/2019/09/13533.php</a><br>
</blockquote></div>
_______________________________________________<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>