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

Re: w3m -> standard, lynx -> optional

Somebody wrote in a personal e-mail to me:
> In article <1h5kQ-7Kd-31@gated-at.bofh.it> you wrote:
> > Sounds interesting. My point was more about nl_langinfo(CODESET) than
> > about iconv, i.e. if $webserver sends a file with "Content-Type:
> > text/plain; charset=utf-8" and my terminal is running in with a
> > ISO-8859-1 font I'd want the browser to convert automatically (without
> > me switching a "my terminal is using charset ____" menu-item everytime
> > I choose to use an uxterm instead of the Linux console) and show
> > "»Bäder«" instead of "»Bäder«"
> It works for lynx.

Indeed, it works this way, checking with

However the other way round is broken, check
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)
ELinks 0.4.3rc2

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.

Redirecting to d-d again.
             cu andreas

Reply to: