Bidi paragraph direction in terminal emulators

[Eli Zaretskii via Unicode]

> Date: Sat, 9 Feb 2019 00:18:14 +0000
> From: Richard Wordingham via Unicode <unicode at unicode.org>
> 
> > For character composition, you must have a shaping engine to talk to,
> > and the shaper should tell you the width of each grapheme cluster it
> > returns.
> 
> (a) What defines the grapheme clusters?  The definition might be
> terminal-specific.

Well, the "you" above alluded to the terminal emulator, of course.
The grapheme clusters are determined by the shaping engine that the
emulator must call when appropriate (or always).

> (b) With a terminal that expects a fixed width font, surely the
> terminal decides how many cells it allocates to a group of characters,
> and the font designer has to come up with a suitable value based on
> that. 

Yes.  A terminal emulator that works with a shaper should probably
post-process the width information returned by the shaper for these
purposes.

> >  I don't see how you can expect wcwidth, or any other
> > interface that was designed to work with _characters_, to be useful
> > when you need to display grapheme clusters.
> 
> Well I can envisage a decision being made that a grapheme cluster str
> (as decreed by the terminal) shall occupy wcswidth(str) cells - "The
> wcswidth() function returns the number of column positions for the
> wide-character string s, truncated to at most length n".

AFAIU, the shaping engine returns its output in terms of font glyph
numbers, not character codepoints, so you cannot in general call
wcswidth on them.  The shaper also returns the advance information,
which serves instead of wcwidth and related APIs for determining the
actual width on display.