Re: (char-code ) inconsistencies

Hi Peter and Terje,

  Many thanks for your prompt and informative replies.  Because several uncompressed image 
file formats (e.g., .psd  and  .bis) use the extended ASCII character-integer mapping, I'll need 
to write a workaround for opening/saving such images.  But at least I know what the issue is 
now.  Thanks again for your help,

  Ray Lee
---- Original message ----
>Date: Mon, 22 Mar 2010 17:44:44 +0000
>From: peter <[email protected]>  
>Subject: Re: [info-mcl] (char-code ) inconsistencies  
>To: Discussion list for MCL users <[email protected]>
>
>At 10:34 AM -0700 10/3/22, Terje Norderhaug wrote:
>>On Mar 22, 2010, at 10:06 AM, Raymond Lee wrote:
>>>
>>>   The (char-code ) function's behavior has 
>>>changed from MCL 5.x to RMCL 5.2.1 and now
>>>appears quite inconsistent for ASCII 
>>>characters > 127.  For example, in most fonts 
>>>ASCII
>>>character #  179 is mapped to the "greater than 
>>>or equal to" character.  But now in RMCL
>>>
>>>  (char-code (character "„")) --> 8805
>>>           whereas
>>>  (char-code (character 179)) --> 179
>>>
>>>   Thus the problem surfaces when you try to 
>>>coerce text (say, in an image file) to its ASCII
>>>equivalent, but it won't appear if you call 
>>>(char-code ) from its inverse, (character ). 
>>>Most ASCII
>>>characters > 127 exhibit similar problems.  Any 
>>>solutions or ideas come to mind?
>>
>>This is due that MCL 5.2 was upgraded to use 
>>Unicode, for which 8805 (2265 hex) is the 
>>"greater than or equal to" character.
>
>Presumably hence char-code's fine, we're just 
>inputting unicode now where we were using roman.
>
>Isn't the lisp function >= rather than „.
>_______________________________________________
>info-mcl mailing list
>[email protected]
>http://clozure.com/mailman/listinfo/info-mcl
_______________________________________________
info-mcl mailing list
[email protected]
http://clozure.com/mailman/listinfo/info-mcl