> 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.
Received on Sat Feb 09 2019 - 12:56:49 CST
This archive was generated by hypermail 2.2.0 : Sat Feb 09 2019 - 12:56:49 CST