[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
lynx-dev Re: 8-bit characters in EDITTEXTAREA
From: |
Kim DeVaughn |
Subject: |
lynx-dev Re: 8-bit characters in EDITTEXTAREA |
Date: |
Wed, 10 Feb 1999 16:37:45 -0800 |
On Wed, Feb 10, 1999, Ismael Cordeiro (address@hidden) said:
|
| On Wed, 10 Feb 1999, Kim DeVaughn wrote:
|
| > It shouldn't be "8-bit chars" that get replaced with a ".", but only
| > "control chars" (ie, chars with numeric values below a SPACE, in either
| > ASCII or EBCDIC).
|
| No, they are not control characters, not even 8-bit control characters
| (128-159). They are ISO 8859-1 printable characters (160-255). When I quit
| the text editor back to lynx they are "translated" to dots.
You've probably already seen my response about not using an (unsigned char)
cast, or iscntrl(). A patchlet will be along shortly.
| Anyway, if
| control characters were not allowed, nobody could use CR (13), LF (10) or
| TAB (9).
Each line of text (or anchor's input data, to be more accurate) is stored
internally as a seperate NULL terminated string. The CR's and LF's that
one uses to move from line to line, do NOT become a part of those strings,
but are instead interpreted by lynx in the same way that a DownArrow key
is ... as a cursor/pointer movement command.
I also had to expand TAB's into SPACES (mod 8), since a TAB in a TEXTAREA
field is also interpreted as a cursor movement command. Ugly Things
happen to normal cursor movement if TAB chars are actually allowed to
become embedded in the anchor's text strings.
| > Currently it is necessary to do *something* with such chars when they are
| > rendered into the TEXTAREA lines. Leaving them as control chars, causes
| > Bad Things to happen, when lines containing them later get submit'ted,
| > etc.
|
| Is there any RFC or similar document saying that control characters are not
| allowed in TEXTAREA?
I don't know. I asked the same question when I started working on this.
What I *do* know is that if they *are* present, the submit'ed data can get
munged in a variety of ways, not to mention causing the cursor movement,
and rendering problems described above.
Whether that is "by spec", or a "lynxism", I do not know.
Now a question for you ...
What reason/requirement do you have for including control (not ALT) chars
in TEXTAREA strings ...?
/kim
Re: lynx-dev Re: 8-bit characters in EDITTEXTAREA, Klaus Weide, 1999/02/11
Re: lynx-dev Re: 8-bit characters in EDITTEXTAREA, Leonid Pauzner, 1999/02/10
lynx-dev [dev16] patch to fix ALT chars in TEXTAREA edit (was: 8-bit characters in EDITTEXTAREA), Kim DeVaughn, 1999/02/10