<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 '\0', 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's hard to solve this problem in general (but it'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>> If no vendor feels that their customers would benefit from a field-width
specifier, then there simply won'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'Dwyer <<a href="mailto:arthur.j.odwyer@gmail.com">arthur.j.odwyer@gmail.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"><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 <format> implementation. If no vendor feels that their customers would benefit from a field-width specifier, then there simply won'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 <<a href="mailto:lib@lists.isocpp.org" target="_blank">lib@lists.isocpp.org</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"><div dir="ltr">Even with monospace fonts you can't just rely on number of characters once you are beyond ASCII. Han characters are often double wide.<br>This kind of formatting can't be made to work in the general case, so we'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 <<a href="mailto:s_sourceforge@nedprod.com" target="_blank">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"><br>
> Perhaps it would be helpful to enumerate what we expect to be portable<br>
> uses of field widths. My personal take is that they are useful to<br>
> specify widths for fields where the content is restricted to members of<br>
> the basic source character set where we already have a guarantee that<br>
> 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>