Re: w3m -> standard, lynx -> optional
Andreas Metzler <ametzler@logic.univie.ac.at> wrote:
> Hello,
> Indeed, it works this way, checking with
> http://www.logic.univie.ac.at/~ametzler/utf-8.html
> However the other way round is broken, check
> http://www.logic.univie.ac.at/~ametzler/iso8859-1.html
> in an uxterm with an UTF-8 locale.
> elinks seems to use iconv even with /TRANSLIT (Oesterreich) but does
> not use nl_langinfo(CODESET) instead it forces me to select the
> charset by hand in the menu.
> I have tested with current sid, i.e.:
> Lynx Programmversion 2.8.4rel.1 (17 Jul 2001)
> w3m/0.4.2
> ELinks 0.4.3rc2
That's an apples & oranges comparison, btw. I see that lynx-cur (which
is what you should have cited) is built with ncurses rather than ncursesw
(a problem for this comparison).
> Term-/content-charset w3m lynx elinks
> iso-8859-1/iso-8859-1 yes yes yes[1]
> iso-8859-1/utf-8 no yes yes[1]
> utf-8/iso-8859-1 no no yes[1]
> utf-8/utf-8 no no yes[1]
> [1] manually set terminal character-set to 7-bit ASCII, results
> in transliteration to "Oesterreich".
> ELinks looks better than it is in the table, as it does not
> support outputting UTF-8 at all, so it will probably fail completely
> in UTF-8-term for characters which cannot be transliterated.
> I was quite surprised about both lynx' and w3m failing to display
> utf-8 text in an utf-8 terminal.
lynx can, if it is packaged properly. For more than a year (2.8.5dev.7).
otoh, I haven't _seen_ elinks doing utf8 properly. ymmv.
--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
Reply to: