lynx-dev Re: msg00798.html (was: 0x2276 handling)

[Leonid Pauzner]

>         To illustrate this further, in that FAQ, for each line which has CJK
> dibyte characters the author has placed a line with homologous ASCII strings
> below it.  For non-CJK document charsets, which Lynx can handle via
> Unicode-based character conversions, that wouldn't (and ideally, should not
> ever) be necessary (we get the Cyrillic or Greek equivalents of "Kung Fu"
> strings automatically :).  Leonid in effect was asking what Lynx should
> do in such cases, but no matter what it does within the contraints of
> the current CJK implementation, the screen display is not going to be
> interpretable in such cases by people who might otherwise "sound out"
> CJK strings converted to ASCII strings.
Correct.
But I was interesting mainly not in fonetic equivalents which may be useful
only for short things like name or address, but more technical and simple issue:
how the `transperent' layout may look like if the character map <256,
e.g. a few 8bit characters are restricted like x80-x9F for iso-8859-x.
There should be a `unified' representation form like numeric UA8UBA...
which I saw under some circumstance.
>
>
> >The truth is, however, I am not having a lot of luck using Win32 Lynx
> >2.7.1ac-0.81, if there is a meta tag describing the character set, e.g.,
> ><META HTTP-EQUIV="Content-Type" CONTENT="text/html;CHARSET=x-euc-jp">.
> >Without a meta tag, a document is rendered okay.  Guess it means I need
> >to upgrade to 2.8.
>
>         That has nothing to do with CJK support, per se, beyond that you've
> set up euc-jp as your assumed charset, and therefore get what you want when
> Lynx has no idea what is the actual charset.  Klaus had bad logic and an
> incomplete list for charset synonyms (which blew it on "x-euc-jp" and
> "x-shift_jis").  He changed the logic to more like what I had in v2.7.2
> and supplemented the synonyms lists equivalently, shortly before he took
> off.
>
>                                         Fote

Actually, 2.8+ ignore META charset if one is CJK (in most cases)
but display is not, I don't know why.
I check the code yesterday but haven't sove the problem.
2.7.2 *seems* do the same job in this area (according to the code).
Assume_charset have only effect here. So today I have fixed ^A in Options,
which was not working `sometimes' until you reload by Ctrl-R.