Bug#354284: lynx vs. uxterm
On Tue, Feb 28, 2006 at 07:40:06AM +0100, Dan Jacobson wrote: T uxterm should be setting the locale (if your shell unsets them, that T would produce the sort of effect you are describing, but is not a bug in lynx). $ HOME=/ uxterm #instead of su -, but same effect. OK, will await dist-upgrade. Tftp://invisible-island.net/temp/db354284-w3m.png Tftp://invisible-island.net/temp/db354284-lynx.png sorry (my typo): Feb 26 14:18 image/pngdb354384-lynx.png 9Kb Feb 26 14:18 image/pngdb354384-w3m.png 8Kb == PASV ... done.== RETR db354284-w3m.png ... No such file `db354284-w3m.png'. Same with the other. Anyways all you need to do is confirm that it looks the same as -dump. No photos needed. As I'm sure it does, further testing will have to await my next http://jidanni.org/comp/debian/apt-offline/index_en.html run. OK thanks. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net pgp15IZyIjsMl.pgp Description: PGP signature
Bug#354284: lynx vs. uxterm
T uxterm should be setting the locale (if your shell unsets them, that T would produce the sort of effect you are describing, but is not a bug in lynx). $ HOME=/ uxterm #instead of su -, but same effect. OK, will await dist-upgrade. T ftp://invisible-island.net/temp/db354284-w3m.png T ftp://invisible-island.net/temp/db354284-lynx.png == PASV ... done.== RETR db354284-w3m.png ... No such file `db354284-w3m.png'. Same with the other. Anyways all you need to do is confirm that it looks the same as -dump. No photos needed. As I'm sure it does, further testing will have to await my next http://jidanni.org/comp/debian/apt-offline/index_en.html run. OK thanks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#354284: lynx vs. uxterm
On Sun, Feb 26, 2006 at 05:50:09AM +0100, Dan Jacobson wrote: Starting over. $ uxterm $ su - # su - nobody $ env TERM=xterm HOME=/ #... etc. No LC_ or LANG stuff. uxterm should be setting the locale (if your shell unsets them, that would produce the sort of effect you are describing, but is not a bug in lynx). $ export http_proxy=http://localhost:8080/; #needed for me, WWWOFFLE $ wget -O - http://zh.wikipedia.org/wiki/%E8%9A%8A%E5%AD%90 #Chinese looks great! $ lynx http://zh.wikipedia.org/wiki/%E8%9A%8A%E5%AD%90 $ export LYNX_CFG=/etc/lynx-cur/lynx-utf.cfg $ lynx http://zh.wikipedia.org/wiki/%E8%9A%8A%E5%AD%90 Nope. No matter what I do, only 1% of the Chinese characters come thru OK, all the rest turn into a tilde mess. wget, w3m work fine. I don't read Chinese, so it would be understandable if I overlook relatively minor things, but I don't see any tildes. Comparing with w3m, the glyphs look the same. I made screenshots to show the two, put them in ftp://invisible-island.net/temp/db354284-w3m.png ftp://invisible-island.net/temp/db354284-lynx.png -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net pgp81pMzG2Qzm.pgp Description: PGP signature
Bug#354284: lynx vs. uxterm
On Sat, Feb 25, 2006 at 12:20:14AM +0100, Dan Jacobson wrote: Package: lynx-cur Version: 2.8.6-17 Severity: normal There is something wrong in what lynx sends e.g., uxterm. $ lynx -dump http://seba.ulyssis.org/thesis/howto-pinyin.php is fine. Nothing to do with raw utf-8 vs. #stuff. if the dump is fine, then it sounds as if you're talking about the interactive display - I don't see any tildes in that (after setting the display character set to UTF-8, of course). And why does = show Charset: utf-8 when o shows Assumed document character set(!): [iso-8859-1__] lynx.cfg says # ASSUME_CHARSET changes the handling of documents which do not # explicitly specify a charset. Normally Lynx assumes that 8-bit # characters in those documents are encoded according to iso-8859-1 # (the official default for the HTTP protocol). When ASSUME_CHARSET # is defined here or by an -assume_charset command line flag is in effect, # Lynx will treat documents as if they were encoded accordingly. # See above on how this interacts with raw mode and the Display # Character Set. # ASSUME_CHARSET can also be changed via the 'o'ptions menu but will # not be saved as permanent value in user's .lynxrc file to avoid more chaos. # #ASSUME_CHARSET:iso-8859-1 -assume_local_charset=UTF-8 no help, -assume_charset=UTF-8 same. file:///usr/share/doc/HOWTO/en-html/Unicode-HOWTO-4.html no help. w3m works fine. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net pgpCcOGH52CUO.pgp Description: PGP signature
Bug#354284: lynx vs. uxterm
Starting over. $ uxterm $ su - # su - nobody $ env TERM=xterm HOME=/ #... etc. No LC_ or LANG stuff. $ export http_proxy=http://localhost:8080/; #needed for me, WWWOFFLE $ wget -O - http://zh.wikipedia.org/wiki/%E8%9A%8A%E5%AD%90 #Chinese looks great! $ lynx http://zh.wikipedia.org/wiki/%E8%9A%8A%E5%AD%90 $ export LYNX_CFG=/etc/lynx-cur/lynx-utf.cfg $ lynx http://zh.wikipedia.org/wiki/%E8%9A%8A%E5%AD%90 Nope. No matter what I do, only 1% of the Chinese characters come thru OK, all the rest turn into a tilde mess. wget, w3m work fine. pstree -Al shows `-xdm---sh-+-icewm |-2*[ssh-agent] `-xterm---luit---bash-+-pstree `-xterm---luit---bash---su---bash---su---sh $ xterm -v XTerm(202) Well, OK I'll try again with 209 or whatever next time I go to town to do my dist-upgrade downloads. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#354284: lynx vs. uxterm
Package: lynx-cur Version: 2.8.6-17 Severity: normal There is something wrong in what lynx sends e.g., uxterm. $ lynx -dump http://seba.ulyssis.org/thesis/howto-pinyin.php is fine. Nothing to do with raw utf-8 vs. #stuff. My investigation concludes that lynx is sending e.g., M-G ~ P when it should be sending M-G M-^P, where M- means high bit set. Instead of setting the high bit of ^P and sending that, it sends two characters, ~ and P. Looking at their bits, ^P 10 0001 P50 0101 ~7e 0110 M-^P 90 1001 we see lynx is sending 11000111 0110 010abcde instead of 11000111 100abcde where abcde varies with the particular char being sent. What a screw up?! Looks like some mis-estimate in your to-utf-8 converter for screen presentation. (pstree shows a xterm--luit connection.) None of character_set=UNICODE (UTF-8) character_set=Transparent character_set=Chinese helped. Display and Character Set Use locale-based character set(!): [ON_] Display character set: [UNICODE (UTF-8)] Assumed document character set(!): [utf-8___] Raw 8-bit (!): [ON_] also didn't help And why does = show Charset: utf-8 when o shows Assumed document character set(!): [iso-8859-1__] -assume_local_charset=UTF-8 no help, -assume_charset=UTF-8 same. file:///usr/share/doc/HOWTO/en-html/Unicode-HOWTO-4.html no help. w3m works fine. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
