> From: Egmont Koblinger <egm...@gmail.com> > Date: Sat, 9 Feb 2019 19:25:08 +0100 > Cc: Richard Wordingham <richard.wording...@ntlworld.com>, > unicode Unicode Discussion <unicode@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.