[SG16-Unicode] [isocpp-lib] New issue: Are std::format field widths code units, code points, or something else?
Corentin Jabot
corentinjabot at gmail.com
Fri Sep 13 17:42:36 CEST 2019
On Fri, 13 Sep 2019 at 15:57, Niall Douglas <s_sourceforge at nedprod.com>
wrote:
> On 13/09/2019 14:36, Victor Zverovich wrote:
> >> Instead of inventing something in the abstract, a good next step would
> >> be to figure out how (in UTF-8 mode) Apple Terminal, Gnome Terminal,
> >> Konsole, and the new Windows Terminal determine how many terminal
> >> display column a string takes. (I'm not volunteering.)
> >
> > I'm volunteering to do this since improving handling of width is already
> > on my TODO list for the fmt library.
>
> I'll be interested in what you come up with on this, as I don't think
> this solvable.
>
> For example, imagine formatting into a file, and then that file is
> rendered onto a console.
>
> Another example: imagine formatting into a clipboard, which on Windows
> and POSIX might involve three or four renditions into differing formats
> and encodings. Then the consumer of the clipboard chooses an unknown one
> of those renditions, and reinterprets it in some unknown way into a
> paste into some document.
>
> Personally speaking, I think the best course is to declare codepoint or
> byte based formatting widths, and draw a line under it.
>
Code-points is even less useful than bytes.
Bytes or perceived characters, aka egcs.
I agree that nothing else has value in the context of the standard
>
> Niall
> _______________________________________________
> SG16 Unicode mailing list
> Unicode at isocpp.open-std.org
> http://www.open-std.org/mailman/listinfo/unicode
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.open-std.org/pipermail/unicode/attachments/20190913/00d93050/attachment-0001.html
More information about the Unicode
mailing list