And stdout is not rich enough for dealing with rendering issues. The
program producing text is entirely decoupled from details of how the
terminal renders.

On Wed, Sep 11, 2019 at 5:23 PM Lyberta <lyberta_at_[hidden]> wrote:

> Corentin Jabot:
> >> The SG16 Unicode group might even end up using "Why does <format> not
> >> support field widths?" as a teachable example, similar to how we use
> "Why
> >> does vector not support push_front()?" as a teachable example.
> >>
> >
> > Not unreasonable to postpone that feature imo
>
> I suggest postponing field width until C++23. Hopefully, by that time we
> have enough experience with both std::format and char8_t and have some
> proposal for Unicode streams so we know from experience what to
> standardize.
>
> My opinion on Unicode terminal is that for every EGC terminal has to ask
> the font renderer if it can render that in a single glyph. If it can't
> (common case for emojis with gender modifiers) then I guess decompose
> EGC into EGCs that can be rendered and reallocate cells for those.
>
> OR:
>
> Squeeze cells so several glyphs are in a single cell. This preserves the
> alignment in case of, say, table. In this case the terminal has to keep
> size of every column and render each EGC separately. But I would say
> that in all cases terminal has to render each cell separately just to
> prevent bugs in the rendering/layout engine.
>
> OR:
>
> Render each EGC into a temporary buffer and scale the buffer down if it
> is too large. This way the size of the terminal in pixels is fixed but
> broken EGCs will render as sequences of very small glyphs.
>
> So yeah, in all cases you have to ask layout/rendering engine to
> determine field width. No way around that.
>
> _______________________________________________
> SG16 Unicode mailing list
> Unicode_at_[hidden]
> http://www.open-std.org/mailman/listinfo/unicode
>