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
Screenshot_20201217_235848.png
Description: Binary data
_______________________________________________ Lynx-dev mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/lynx-dev
