<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">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>