On Sat, 02 Feb 2019 00:38:04 +0100 Kent Karlsson via Unicode <[email protected]> wrote:
> Den 2019-02-01 19:57, skrev "Richard Wordingham via Unicode" > <[email protected]>: > "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.
