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

[Nelson Henry Eric]

> >This mixed-bag page seems a "natural" for Asada's wizardry, and indeed
> >is pretty much rendered correctly by using Lynx in CJK mode on either
[...]
>       I'm concerned, Henry, that you missed the point, and are again
> making unfounded assumptions about the code, which might inadvertantly

Fair enough.  All I was saying is that I don't think the code has any way
of determining that the document in question, or others like it, is a
"mixed-bag", and that if someone _wants to read it as intended_, they
would have to _manually make the decisions_, i.e., override chartrans.

> derail the needed input from CJK users.  The CJK support in Lynx is
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^
I thought my input was appropriate as one of the nearly extinct CJK user(s).

> an unfortunately large extent the Unicode-based chartrans integration,
> is content to have the CJK support *really* work only selectively, i.e.,
> in the case where you *do* have a CJK Display Character Set, and the
> document *does* contain corresponding CJK character representations.

My point again is that this part, the "*does* contain corresponding CJK
character", would essentially require putting the Sato/Asada functions
_before_ the chartrans functions in order to make a halfway intelligent
decision.  That would be inefficient, if not absurd.  Also the Sato/Asada
implementation in Lynx does not support the 7-bit kana AFAIK.

[...]
> document charset is not complementary to the CJK Display Character Set
> (you've set it to assume that it is), Lynx does use the Unicode-based
> chartrans support to convert from the known or assumed Unicode-supported
[...]

Not absolutely sure this is working properly, but in principle it seems
to be desirable.

> strings automatically :).  Leonid in effect was asking what Lynx should

Thank you, Leonid.  And keep up the good work!

> 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"

I waded through all this, but I still don't understand that what you're
saying is any different from what I was trying to say.  Sorry.

> >2.7.1ac-0.81, if there is a meta tag describing the character set, e.g.,=
[...]
>       That has nothing to do with CJK support, per se, beyond that you've

My whole discussion has nothing to do with either CJK or chartrans, per se.
It has to do with making the decision as to which one to use against a
document which is not labeled.

> Lynx has no idea what is the actual charset.  Klaus had bad logic and an

My arguement is that there is no failsafe logic other than doing the kind
of juggling and double guessing that Asada does, for every known language.

In the final analysis, it might be wise to split the entire chartrans and
CJK support out of Lynx, and instead offer compile time switches to choose
which language-version Lynx to build.  That would solve the message translation
problem, too.  For example, the MSIE and Netscape I have available are
Japanese versions.  In fact, they run circles (except for Netscape's "bad
logic" [much worse than Klaus's] concerning meta tags) around Lynx when it
comes to the *real* Japanese language world ww.  They can't handle Russian,
whereas Lynx can.  The choice is one of eclecticism versus specialization.
Klaus made the decision for Lynx.  Lump it or leave it.  Or change it and
improve it.  Sadly, I can only do the former.  Some lucky few I know can
do the latter.

__Henry