Date: Fri, 13 Sep 2019 06:36:47 -0700
> 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_[hidden]> wrote:
> On Thu, Sep 12, 2019 at 4:08 AM Thiago Macieira <thiago_at_[hidden]>
> 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_[hidden]
> https://hsivonen.fi/
> _______________________________________________
> SG16 Unicode mailing list
> Unicode_at_[hidden]
> http://www.open-std.org/mailman/listinfo/unicode
>
> 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_[hidden]> wrote:
> On Thu, Sep 12, 2019 at 4:08 AM Thiago Macieira <thiago_at_[hidden]>
> 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_[hidden]
> https://hsivonen.fi/
> _______________________________________________
> SG16 Unicode mailing list
> Unicode_at_[hidden]
> http://www.open-std.org/mailman/listinfo/unicode
>
Received on 2019-09-13 15:37:01