lynx-dev
[Top][All Lists]
Advanced

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

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


From: Leonid Pauzner
Subject: Re: lynx-dev Re: 8-bit characters in EDITTEXTAREA
Date: Fri, 12 Feb 1999 12:15:21 +0300 (MSK)

11-Feb-99 13:33 Kim DeVaughn wrote:
> On Thu, Feb 11, 1999, Leonid Pauzner (address@hidden) said:
> |
| >> OK ... a cast to (unsigned char) is what we'll do.
> |
> | more appropriate check should reject characters
> | from 127..(LYlowest_eightbit[current_char_set] - 1) range
> | since we are working in display charset which may be inconsistent with 
> locale
> | so iscntrl() may return a wrong result on any platform.

> Let me be sure I understand what you're suggesting.

> You're saying that chars in that range should be rejected (actually,
> translated to a "benign" char such as a "."), in *addition* to the
> usual 0x00-0x1f control chars.  Correct?
yes, they are restricted and may introduce more problems
if lynx or remote script will not filter them out on a later stage
(no guarantee).

> OK.  But grep'ing about, I see references to "old-style mapping" (vs. the
> "chartrans mechanism") in code such as (from LYCharSets.c):

No problem, LYlowest_eightbit[charset] is a charset property,
both for "old-style" and "chartrans" charsets.

Well, LYCharSets.c whould be rewritten some day.

>   /*
>    *  Add the code of the the lowest character with the high bit set
>    *  that can be directly displayed.
>    *  The order of LYCharSets and LYlowest_eightbit MUST be the same.
>    *
>    *  (If charset have chartrans unicode table,
>    *  LYlowest_eightbit will be verified/modified anyway.)
>    */
>   PUBLIC int LYlowest_eightbit[MAXCHARSETS]={
>           160,    /* ISO Latin 1          */


> Can I assume [I hate that word] that  LYlowest_eightbit[current_char_set]
> by now always has ordinal of the 1st high-order-bit-set character, and
> that no "special casing" is required to accomodate "the old way" vs. "the
> new way"?

> If so, I can easily add a check to see if such chars are in the edited
> data, and convert them if that should happen.

> I presume [better than assume :-) ] that such a check would NOT apply
> to EBCDIC platforms.  BTW, anyone know why there is no character set
> definition for EBCDIC (that I could find, anyway)?

I have no idea about EBCDIC

> /kim



reply via email to

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