unidecode broken on Intel Macs?

[Mark Smith]

A big-endian (motorola) unicode character will be in the form : msb  
lsb, so if the character falls within the ascii range, say "A", then  
it will be <numToChar(65) numToChar(0)>.

If it's in little-endian (intel) format, the same char will be  
<numToChar(0) numToChar(65)>.

Unidecode simply removes the most significant byte of each unicode  
char/pair, so on Intel, thats the second byte, and on motorola that's  
the first byte.

So the upshot is that if your data is big-endian (motorola), then to  
work with unidecode on intel, you'll need to swap each pair of bytes.

function swapBytes pString
   repeat with n = 1 to length(pString) - 1 step 2
     put char n+1 of pString & char n of pString after swappedString
   end repeat
   return swappedString
end swapBytes

I'm hoping that we'll get a complete revamp of Revs unicode handling,  
one of these days, but we're stuck with this sort of thing for now. :(

Best,

Mark

On 1 Aug 2007, at 13:54, Klaus Major wrote:

>
> Ah, I see...
> ??? :-)
>
> Maybe you could get a TINY BIT more specific?
>
>> Best regards,
>>
>> Mark Schonewille
>>
>> --
>>
>> Economy-x-Talk Consulting and Software Engineering
>> http://economy-x-talk.com
>> http;//www.salery.com
>
> Regards
>
> Klaus Major
> klaus at major-k.de
> http://www.major-k.de
>
>
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your  
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution