lynx-dev
[Top][All Lists]
Advanced

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

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


From: Klaus Weide
Subject: Re: lynx-dev reading sjis docs [was Re: lynxcgi problem]
Date: Tue, 4 Jan 2000 20:42:19 -0600 (CST)

On Tue, 28 Dec 1999, Henry Nelson wrote:

> > IMHO: I agree that lynx should be able to do as much as possible
> > internally becuase it would lend an image of lynx being unable to cope
> 
> That's in a sense exactly what I am saying and why I started this thread.

A nitpick here, maybe, but I think it's important:
(let me know if you think not...)

> By putting the manual override switch to choose the document encoding
> (AUTO, EUC, SJIS) _into_ Lynx does not make Lynx better able to cope.

A user can never "choose the document encoding", in a literal usage of
those words.  That would mean that the user can _choose_ how the document
*is* encoded.  But of course the *author* (or his tools) already did that.
All the user can really choose is the assumption *about* that encoding
that *his* tools should make.

I've always found that use of terminology highly confusing with Netscape.
IMO it contributes a lot to the confusion in this whole area.  That is
why Lynx's settings for this have an explicit "assume..." in the name,
I tried to do better (although this doesn't carry over to the "raw"
terminology...).  I assume that choosing an "*assumption*" about the
document encoding (just at a different level, which doesn't really "talk to"
Lynx's other ASSUME_* settings well) is what the CJK_EX 'manual override
switch' does; but, having never used it, I don't feel quite sure I
understand right if the, IMO, unclear terminology is used in describing
it.

> I am confident that the AUTO mechanism of Lynx can be improved to make it
> as good as any other browser out there.  _That_ would be making Lynx
> better able to cope.  Where the user's judgment is absolutely necessary
> (EUC or SJIS manual override), then I am saying you might as well leave
> it totally up to the user, because then you can have a number of ways
> to convert the encodings and/or handle a particular document.  Now that
> is something no other browser I know of could do.

So it seems you are saying hat Lynx should do better internally, and that
it also good that one can do things externally if necessary.  Just what
is the argument about? :)

> > Okay for little used features (err canne think of one ATM) then point them
> > to the outside but otherwise it would be better to suggest configure
> 
> CJK is a minority feature, and we are talking about only one aspect of it.

But the decision whether Lynx should support CJK internally has been made,
a long time ago; now it should do the best possible job of it.

> However, my way of thinking is the opposite.  Where Lynx runs circles around
> the other browsers out there is exactly those "outside" ways of doing things:
> lynxcgi, lynxprog, lynxexec, external, download, or printer.  Letting these
> fall into disuse is a waste of Lynx's talents.

In principle I agree...  but maybe for CJK conversion support, it *should*
do much better than it currently does, without external help.


   Klaus


reply via email to

[Prev in Thread] Current Thread [Next in Thread]