Re: LYNX-DEV more chartrans

[Leonid Pauzner]

> > One more here, about charset assumption if we have 7bit text.
[...]
> > Is it possible to test new coming page whether it have 8bit or not,
> > and set the appropriate variable to us-ascii in the code?
[...]
>
> This doesn't apply to the charset shown with '=', but I don't see why it
> should.  If you use '=', I "assume" you want to know what charset was in
> effect for a document, independent of whether this has any practical
> effect for a specific document, or has no effect (because there weren't
> any non-ASCII raw characters).
>

I suppose you look from the "ISO-latin-1 point of view".
May be this solution can be applyed:
if you have display charset other than ISO-Latin-1 (or its superseeds?)
show us-ascii for '=' if it really happens (charset has not specified
and should be assumed, but high bit not detected).


> A "©" gets translated to an 8-bit character if the display character
> set has it; that is independent of whatever charset is in effect for the
> original text.  If you mail the result, Lynx will normally generate a
> charset parameter in the mail headers, so the recipient can know what is
> what. If you really have to avoid that, you can use "7 bit approximations"
> as display character set.  Or convince the page authors not to put
> copyright notices on their pages...

Ah...

One problem may be explained here:
roughly 1/2 of charsets have not (c) sign, especially on MSDOS PC and ISO/=1.
Out of Lynx, usual translation tools may only convert symbols one-by-one.
I my case, if I have koi8-r display and p)rint to e-mail,
the recipient with cp866 always get copyright smashed by
mysterious pseudographic character,
so it is very close to your last sentence...

(Yes, possible to set display to cp866, but we get problems outside Lynx.)
Seems there is no good solution for interoperability here.
leave as is.