lynx-dev reading sjis docs [was Re: lynxcgi problem]

[Hataguchi Takeshi]

On Wed, 22 Dec 1999, Henry Nelson wrote:

> Actually, what this whole afair is about is that I finally had a chance
> to look at an sjis page that supposedly Lynx could not render because of
> those 1-byte kana we were discussing the other day.  Already I was
> disappointed in the way Hiroyuki had chosen to handle such pages: a
> manual override.  There is no need for that approach as it is best done
> outside of Lynx (like so many other things I harp about).  Appended is

I can't understand why you wrote "it is best done outside of Lynx".
I know that it's one considerable way to solve the probrem, 
but Hiroyuki's approach is as considerable as it. 
I'm not sure which is better but for beginners Hiroyuki's approach
may be better.

# It's not so smart, but I think it's practical.

And I think if NKF handles 1-byte kana well, 
it means there is a room to improve Lynx to handle them well.
I want to try this in the near future. Could you tell me the pages 
which Lynx can't render well since they have 1-byte kana?

> What really shocked me, however, was that the page I was asked to look
> at had the header:
> <meta http-equiv="content-type" content="text/html; charset=x-sjis">.
> Is Lynx ignoring that "charset=x-sjis?"  Somehow I had in my mind that
> Lynx parsed and used the information in those META tags, Netscapism or
> not.  If Lynx can determine the charset of the document from the META,
> then certainly there should be no need for a manual override.  The
> reason I didn't say much about it at the time is that I thought we were
> talking about those all-too-many documents which are not declared
> either by the server or a META in the document.  What would it take to
> use that "x-sjis" to trigger better performance of the code-conversion
> routines, and leave as a last resort manual override (or proxy/gateway)
> handling?

I agree.
--
Takeshi Hataguchi
E-mail: address@hidden