From: rnelson@wsuaix.csc.wsu.edu (roger nelson;S23487) Subject: Re: 8 bit clean implies what? Date: Mon, 8 Feb 1993 20:22:05 GMT
In article <1993Feb6.224910.3822@chpc.utexas.edu> michael@chpc.utexas.edu (Michael Lemke) writes:
>In article <DAVIS.93Feb6161629@pacific.mps.ohio-state.edu> davis@pacific.mps.ohio-state.edu (John E. Davis) writes:
>>In article <1993Feb6.203811.24134@chpc.utexas.edu> michael@chpc.utexas.edu
>>(Michael Lemke) writes:
>> ...accepting 8bit controls will use them. Secondly, an 8bit clean editor
>> needs to know what are corresponding uppercase and lower case
>> characters, e.g. å is lower case of Å.
>>
>>This is an excellent point that I have not thought of. The natural solution
>>is through the use of a lookup table. But, in general, this requires TWO
>>tables: uppercase and lowercase. However, a single CHANGE_CASE table is
>>sufficient if it is guaranteed that lower_case(x) >= upper_case(x). Does
>>anyone know if this assumption is valid?
>
>
>Yes, this is true for at least ISO-Latin-1 and DEC Multinational
>Character Set (almost identical). The high order part of these char
>sets are pretty much an image of the low order part except the 8th bit
>is 1. You should really have a look at the ISO-Latin-1 character
>tables, for example in the appendix of a terminal that has 8bit chars
>(e.g., vt220 and higher, GraphOn225 and higher). Also think about sort
>sequences. An ANSI C implementation must provide functions like
>isupper(int C) which are controled by the current locale which in turn
>is controled by the setlocale function. I haven't done anything with it
>but this is exactly the kind of problem the stuff was invented for.
>The world isn't ASCII anymore.
>
>Michael
>--
>Michael Lemke
>Astronomy, UT Austin, Texas
>(michael@io.as.utexas.edu or UTSPAN::UTADNX::IO::MICHAEL [SPAN])