[Top][All Lists]

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

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

From: Jacob Poon
Subject: Re: lynx-dev Re: msg00798.html (was: 0x2276 handling)
Date: Tue, 5 May 1998 12:23:08 -0400

On Mon, 4 May 1998, Leonid Pauzner wrote:

> >         That bug report from Poon reflects a lack of understanding about
> > the difference between the document charset and the Display Character Set.
> > What he describes Lynx as doing appears to be what it should be doing.
> > However, I tracked down a URL for the FAQ (would have been nice if he had
> > included it the the message):
> >
> >
> >
> > and when I tried it with the W32 binary, it did what he thought it should
> > do, and is wrong.  The server is returning "Content-Type: text/plain"
> > without a charset parameter, so the assumed charset should apply, and
> > both the 'o'ptions page and the ShowInfo Page ('=') confirm that I have
> > it set as iso-8859-1.  Yet it looks as though CJK multibyte characters
> > in the iso-8859-1 control character range are being handled as DosLatinUS
> > characters for what is sent to the screen (does that binary use the
> > "work with MicoSoft sins" assumption that some of those are Windows
> Currently it displays &#nnn from x80-x9F range as WINDOWS-1252 codepoints
> (inflicted by FrontPage), but not display it in ALT= :-(
> If the document is or assumed as iso-8859-1,
> control characters (x80-x9F) ignored sighlently if happend.
> you mean they should be assumed as windows-1252 ?

OK, let's make another suggestion on this.  Lynx.cfg should add an option
ASSUME_UNREC_CHARSET directives to view such unrecognized documents with
the same display character set as stated in the CHARACTER_SET directive.
If not, we may need to adjust those 3 directives within Lynx.

reply via email to

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