Re: lynx-dev Re: 8-bit characters in EDITTEXTAREA

[Laura Eaves]

> From: "Leonid Pauzner" <address@hidden>
> Date: Thu, 11 Feb 1999 13:22:25 +0300 (MSK)
>...
> > The question still remains as to how charsets should be
> > handled wrt text entry fields.  The most intuitive approach (n my mind)
> > would be to accept input in assumed charset (which would also be the value
> > submitted in the form) but translated to display charset for output to
> > the screen, unless raw mode is ON.
> > What is your view?
>
> The internal Lynx charset (e.g. HText data) is "display charset",
> it is supposed that your font, keyboard (e.g. for search "/"),
> and external editor all worked well for this charset.
> So the form's entry fields are in display charset.
> When submitting forms, lynx translate input fields back from display charset
> to the document charset (or assumed... if it was not set explicitely)
> so the remote server will not receive unexpected encodings.
> I am using lynx for search engins with cyrillic input text - it works OK.
> (According to HTML 4.0, there is a possibility to set submitting charset
> inside <form charset=...> syntax, I hope lynx do this either,
> though I have not tested the details).

Perhaps I'm confused.
It still looks as if input is not accepted in display charset.
Example: alt135 in my display charset (cp437)   should be c-cedil, but is
ignored when I enter it in a text entry field, whereas alt231 (c-cedil in
my assumed charset (iso-8859-1) is accepted and displays as tau (alt231 in
cp437).

>...
> You see the ignorance of alt135 when you enter keys or you got such result
> back from the remote server' replay?

I'm not sure.  When I enter alt135 at my shell prompt I get the expected
chars displayed.  When I enter alt135 in text entry in lynx, it behaves as
above.

Thanks for your reply.
--le