lynx-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Thorsten Glaser
Subject: Re: [Lynx-dev] Only half CJK characters displayed
Date: Thu, 17 Dec 2020 23:01:09 +0000 (UTC)

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:

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.

Perhaps lynx positions the glyphs one by one.

> 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.

bye,
//mirabilos
-- 
[...] if maybe ext3fs wasn't a better pick, or jfs, or maybe reiserfs, oh but
what about xfs, and if only i had waited until reiser4 was ready... in the be-
ginning, there was ffs, and in the middle, there was ffs, and at the end, there
was still ffs, and the sys admins knew it was good. :)  -- Ted Unangst über *fs

Attachment: Screenshot_20201217_235848.png
Description: Binary data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]