lynx-dev
[Top][All Lists]
Advanced

[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: Thu, 11 Feb 1999 13:33:26 -0800

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?

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

  /*
   *  INSTRUCTIONS for adding new character sets which do not have
   *               Unicode tables.
   [...]
   *
   *  [We hope you need not correct/add old-style mapping
   *  as in ISO_LATIN1[] or SevenBitApproximations[] any more -
   *  it works now via new chartrans mechanism, but kept for
      compatibility only:
   *  we should cleanup the stuff, but this is not so easy...]

and

  /*
   *  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)?

/kim

reply via email to

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