<div dir="ltr">Just a small followup on our discussion of P0645 Text Formatting during the previous meeting.<br><br>1. Interpretation of width with multibyte encodings and combining characters.<br><br>P0645R2 currently doesn&#39;t specify the units of width. Possible options are (from lower to higher abstraction level):<br><br>* Code units<br>* Code points<br>* Grapheme clusters<br><br>Python 3 uses code points as can be seen from the following example:<br><br>&gt;&gt;&gt; o = b&#39;\x6F\xCC\x88&#39;.decode(&#39;utf8&#39;)<br>&gt;&gt;&gt; o<br>&#39;ö&#39;<br>&gt;&gt;&gt; &#39;{:&gt;2}&#39;.format(o)<br>&#39;ö&#39; # note missing space<br>&gt;&gt;&gt; o = b&#39;\xC3\xB6&#39;.decode(&#39;utf8&#39;)<br>&gt;&gt;&gt; o<br>&#39;ö&#39;<br>&gt;&gt;&gt; &#39;{:&gt;2}&#39;.format(o)<br>&#39; ö&#39;<br><br>I have slight preference to grapheme clusters because according to <a href="http://unicode.org/reports/tr29/">Unicode Standard Annex #29 UNICODE TEXT SEGMENTATION</a> they correspond to “user-perceived characters” (at least that seems to be the intention, whether they are successful in that is another question).<br><br>Zach provided an example of <span style="font-size:small;text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">&quot;👨\u200D👩\u200D👧\u200D👦&quot;, <span style="background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">where \u200D is a zero-width joiner (ZWJ),</span> rendered as a single glyph representing a family <span style="background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">&quot;👨‍👩‍👧‍👦&quot;. However, if I interpret the following part of <a href="http://www.unicode.org/reports/tr29/tr29-29.html#GB10">http://www.unicode.org/reports/tr29/tr29-29.html#GB10</a> correctly:</span></span><div><br></div><div>&gt; Do not break within emoji modifier sequences or emoji zwj sequences.</div><div><br></div><div>this is not a problem and <span style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">&quot;👨\u200D👩\u200D👧\u200D👦&quot; will constitute a single grapheme cluster.</span></div><div><br></div><div>That said, making grapheme clusters width units may add significant complexity to the implementation with minor benefits, so I&#39;m fine going with code points especially since there is an established example of doing this (Python) and it&#39;s already an improvement over stdio &amp; iostreams.</div><div><div><br></div><div>2. Interpretation of fill.</div><div><br></div><div>It seems there was a general agreement that fill should be a code point but please let me know if you have other ideas.</div><div><br></div><div>3. There was a question about <span style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">signed and unsigned char. I checked and there is no special handling for these types which means that they are treated as integral types, only char and wchar_t are treated specially as character types (and later charN_t will be added).</span></div><div><br></div><div>4. Interpretation of n in format_to_n.</div><div><br></div><div>There was no agreement whether n should be specified in code units or code points. An argument in favor of code units is that n often gives the output buffer size. On the other hand, using code points would be more consistent with width.</div><div><br></div><div>I plan to add support for specifying width and fill as code points in fmt (<span style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">Zach gave some useful pointers on how to do that, thanks!) and will report back with any user feedback.</span></div><div><br></div></div><div>Cheers,</div><div>Victor</div></div>