Proposal for BiDi in terminal emulators

Richard Wordingham via Unicode unicode at unicode.org
Fri Feb 1 20:06:15 CST 2019


On Sat, 02 Feb 2019 00:38:04 +0100
Kent Karlsson via Unicode <unicode at unicode.org> wrote:

> Den 2019-02-01 19:57, skrev "Richard Wordingham via Unicode"
> <unicode at unicode.org>:

> "Monospaced font" is really a concept with modification. Even for
> "plain old ASCII" there are two advance widths, not just one: 0 for
> control characters (and escape/control sequences, neither of which
> should directly consult the font; even such things as OSC sequences,
> but the latter are a bad idea to have in any line one might wish to
> edit (vi/emacs/...) via a terminal emulator window). But terminals
> (read terminal emulators) can deal with mixed single width and double
> width characters (which is, IIUC, the motivation for the datafile
> EastAsianWidth.txt). Likewise non-spacing combining characters should
> be possible to deal reasonably with.

I remember Michael Everson getting scant sympathy here when he
complained that his 'monospaced' font was rejected as such because
combining characters had zero width.  The rule his font fell foul of
invites distinct NFC and NFD forms of the same string to be rendered
differently; it does not observe the spirit of canonical equivalence.

> It is a lot more difficult to deal with BiDi in a terminal emulator,
> also shaping may be hard to do, as well as reordering (or even
> splitting) combining characters. All sorts of problems arise;...

Which is why Egmont is here looking for comments and advice.

Not all terminal emulators can deal with non-spacing combining
characters. I have recent having unpleasant experiences with what
appears to be Wikimedia's CodeEditor; it expects even non-spacing Thai
vowel marks to have an advance width of one cell.  The text is rendered
in GUI style, i.e. according to the font selected somehow, but the
cursor is positioned according to the character count.  I haven't yet
investigated its treatment of control characters.  I think I'm going to
have to make a font that works to its assumptions.

Richard.


More information about the Unicode mailing list