Back With Unicode Blues

Tuviah M Snyder diskot123 at
Sat May 31 12:11:41 EDT 2003

>I've made a stack that illustrates the Unicode problem I've
>encountered. Anyone interested in helping us find a solution, can
>access it by typing the following inside Revolution's  'messageBox'
>- while you are connected to the internet:
>open stack URL ""
>The stack was made under MacOS X - I don't know how the unicode
>characters will appear or how the scripts will behave under other
>platforms. All feedback appreciated!!!
There is a sample stack in the contributors which demonstrates
transferring unicode text from one field to another
>Like many others, I'm having trouble getting my head round the new 
>unicode features. But I get the impression it's not a good idea to 
>directly manipulate the text of the field itself. (I know it didn't 
>contain what I expected when I first started playing around.) First 
>get the unicodeText, play with that, and then set the unicodeText 
>again. But I guess we have to be careful with chunk expressions.
Right. Because a field can contain a mix of unicode and ASCII text. So if
your planning to write application which work with all languages better
to get the unicodeText of a field, to get the contents of a field as all

It also appears to me, after playing with this issue some more that it
would be conveniant, that if a field uses a unicode font (ie. 'arial,
unicode' or 'osaka, japanese'), that all text in that field should be
stored as unicode. This would make things easier for developers, because
at least they can then directly manipulate a field and know it's all
unicode.  What currently happens is it only stores high bit characters
(ie. > 255) as unicode, so if you have a field whose textfont is 'osaka,
japanese' and type an 'A' Rev saves it as ASCII and sets the textfont of
that character to just Osaka.

Tuviah Snyder <tuviah at> <>
Runtime Revolution Limited - Software at the Speed of Thought

More information about the use-livecode mailing list