Bidi paragraph direction in terminal emulators

[Eli Zaretskii via Unicode]

> From: Egmont Koblinger <egmont at gmail.com>
> Date: Sat, 9 Feb 2019 19:25:08 +0100
> Cc: Richard Wordingham <richard.wordingham at ntlworld.com>, 
> 	unicode Unicode Discussion <unicode at unicode.org>
> 
> > You need to use what HarfBuzz tells you _instead_ of wcswidth.  It is
> > in general wrong to use wcswidth or anything similar when you use a
> > shaping engine and support complex script shaping.
> 
> This approach is not viable at all.
> [...]

I'm probably missing something, because I don't see the grave problems
you hint at.  Any width provided back by a shaper can be rounded to
the nearest integral character cell, so your canvas can still remain
rectangular.  And I see no reason why an application should be
bothered by the actual number of character cells occupied by the text
it wrote on display.  So what exactly is not viable in using the width
reported back by the shaper?

> If you say that the font should determine the logical width, you need
> to start building up something brand new from scratch.

Are you saying that a terminal cannot work with variable-pitch fonts?

> Terminal emulators do have strong limitations. Complex text rendering
> can only work to the extent we can squeeze it into these limitations.

No one said anything to the contrary, AFAICT.