Re: [Lynx-dev] Only half CJK characters displayed

[Thomas Dickey]

On Thu, Dec 17, 2020 at 11:01:09PM +0000, Thorsten Glaser wrote:
> David Woolley dixit:
> 
> > I can't think of any reason why Lynx would get its hands dirty with such
> > details; it is a character cell display browser.  The only thing it
> > needs to know about CJK characters is that they are double width, and it
>
> Me either. I think there’s something about the wcwidth data and OS
> integration (I have had similar effects when glibc, xterm, screen
> and the program in question (lynx, editor, …) had diverging wcwidth
> data; many software, including screen and some xterm builds, bundle
> it, so they work independend of the OS which may even lack UTF-8
> support. When ssh comes into play it gets even more difficult, to
> the end I submitted patches to glibc to fix its wcwidth data and
> built my own patched version of GNU screen — a lot of software takes
> “character width” data from libglib these days, which is absolutely
> unsuitable for a character-cell terminal.)
> 
> The alacritty rendering is definitely somewhat weird compared to
> xterm (see attached screenshot) and also more spacious. Hmm. It
> is not packaged in Debian, I can’t easily test it locally.
> 
> > seems to be getting that right.
> […]
> > occurrences of "移動", 動 is truncated, but 移 isn't, but both are present.
> 
> Asides from alacritty bundling its own width data and that not
> matching the wcwidth data, I suspect the following:

I've only seen it in Arch Linux
(which is where I test its terminal description)
 
> wcwidth(動) is 1, not 2; perhaps because the POSIX locale is not
> set properly and/or because lynx is not set to follow the POSIX
> locale.

wcwidth generally ignores the locale.
But ncurses pays attention.

If lynx isn't using the proper locale,
I'd not expect the overall layouts to match.
 
> Perhaps lynx positions the glyphs one by one.

I'd be surprised if ncurses is doing _that_ :-)

From the lack of other comments, I'm expecting that lynx is from package
(not self-built).
 
> > Assuming a GUI font renderer hasn't been bolted on, and Linux or
> > similar, I'd suggest running lynx under script, to capture the exact
> > byte sequence being sent to the terminal emulator.
> 
> That would certainly help clearing this up.

That's where I'd start (typescript for both pictures, of course).

Any of lynx, ncurses or alacritty could be padding the second half of
double-width cells, but the typescript files would demonstrate if
alacritty is doing it.

-- 
Thomas E. Dickey <dickey@invisible-island.net>
https://invisible-island.net
ftp://ftp.invisible-island.net

signature.asc
Description: PGP signature