[info-mcl] (char-code ) inconsistencies
ron at flownet.com
Mon Mar 22 23:26:10 CDT 2010
More likely all you need to do is change the default encoding to latin-1.
On Mar 22, 2010, at 8:23 PM, Raymond Lee wrote:
> 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 <p2.edoc at googlemail.com>
>> Subject: Re: [info-mcl] (char-code ) inconsistencies
>> To: Discussion list for MCL users <info-mcl at clozure.com>
>> 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
>>>> character # 179 is mapped to the "greater than
>>>> or equal to" character. But now in RMCL
>>>> (char-code (character "„")) --> 8805
>>>> (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
>> info-mcl at clozure.com
> info-mcl mailing list
> info-mcl at clozure.com
More information about the info-mcl