[SG16-Unicode] [isocpp-lib] New issue: Are std::format field widths code units, code points, or something else?
Victor Zverovich
victor.zverovich at gmail.com
Fri Sep 13 15:36:47 CEST 2019
> 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.
> Storage implies code unit count. Do people actually use, _with
> Unicode_, fields of storage that are so fixed-width that they need to
> be padded to the full storage width _and_ do they use std::format to
> do so? (I guess anything is possible, but this seems to me like a very
> specialized niche use case whose premise is a bad idea.)
>From my experience such uses are extremely rare. As I wrote earlier the
main use case for width is visually aligning the text.
P.S. Henri, thanks for the blog post. It was very insightful and timely.
- Victor
On Wed, Sep 11, 2019 at 11:06 PM Henri Sivonen <hsivonen at hsivonen.fi> wrote:
> On Thu, Sep 12, 2019 at 4:08 AM Thiago Macieira <thiago at macieira.org>
> wrote:
> > But I think that we clearly have two distinct uses: a code unit count for
> > storage purposes and a cell grid (monospace font) count for alignment
> > purposes. Note how maxima and minima are inverted: usually, if you're
> trying
> > to align you need to specify a minimum, but if you're trying to ensure
> > something fits a storage, you specify a maximum.
>
> Having stuff line up on a terminal grid in the Unicode context calls
> for East Asian Width (in the mode that resolves ambiguous characters
> as narrow). The concept ignores lots of scripts, but many of those
> scripts have properties such that combining those scripts with the
> notion of having stuff line up on a grid leads to a bad time
> regardless of exact definitions.
>
> 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.)
>
> Storage implies code unit count. Do people actually use, _with
> Unicode_, fields of storage that are so fixed-width that they need to
> be padded to the full storage width _and_ do they use std::format to
> do so? (I guess anything is possible, but this seems to me like a very
> specialized niche use case whose premise is a bad idea.)
>
> --
> Henri Sivonen
> hsivonen at hsivonen.fi
> https://hsivonen.fi/
> _______________________________________________
> 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/15d0ce32/attachment.html
More information about the Unicode
mailing list