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.