[#VWR-422] LSL scripts created on Mac with non-ASCII characters won't compile in Windows viewer

1. Second Life Viewer - VWR

LSL scripts created on Mac with non-ASCII characters won't compile in Windows viewer

Created: 09/Apr/07 06:25 PM Updated: 07/Aug/08 11:52 AM

Return to search

Component/s:

Scripting

Affects Version/s:

1.14.0.x

Fix Version/s:

None

Environment:

Mac OS X 10.4.9, Windows XP SP2, both running on iMac Core Duo

Issue Links:

Duplicate

This issue is original of duplicate:

~~VWR-3784~~ Script compile fails for XP, yet succeeds for Mac and Linux.

~~VWR-2771~~ Script editor: Syntax Error on strings containing "§"

VWR-2561 need scripts to compile with accented character strings

Relates

This issue is related to by:

~~VWR-3857~~ Script (LSL) editor shows non Latin 1 characters as square boxes

VWR-2561 need scripts to compile with accented character strings

Linden Lab Issue ID:

SL-53249

Description

« Hide

LSL script with non-ASCII characters in strings compiles properly on Mac SL viewer, but same script will not compile on Windows viewer. Compile fails with "ERROR: Syntax error" message.

Test Script:
default
{
state_entry()

{ llSay(0, "Hello, Avatar!"); }

touch_start(integer total_number)

{ llSay(0, "Woo hoo! I have an embedded non-ASCII character: °"); // The last character in the string is a degree symbol, Opt-Shift-8 on Mac Keyboard }

}

Also tested with some unicode traditional Chinese, and with Apple symbol, Option-Shift-K. Commenting out lines with non-ASCII characters allows the script to compile in the Windows viewer.

All

Comments

Change History

Sort Order:

[ Permlink | « Hide ]

Zi Ree added a comment - 09/Apr/07 11:47 PM

It also works fine on my Linux viewer but fails on the windows box I have access to.

[ Permlink | « Hide ]

Strife Onizuka added a comment - 10/Apr/07 10:06 PM

Yep, can't get the script to compile.

[ Permlink | « Hide ]

Ima Mechanique added a comment - 06/Jul/07 10:51 PM

This is actually an improvement over the end of 2005, when you couldn't even get the characters to display except as boxes in a script, yet they would display fine in chat, email, just about anywhere else you could think of. It appears there's a problem in the editor's ability to process/hand over unicode characters to the compiler. This may be deliberate as the font the script editor uses it not the same as the other parts of the viewer, and has only a limited number of glyphs in it.

An ugly work-around is to use URL escaping to get the characters into the script. This line:

llOwnerSay(llUnescapeURL("%E2%80%90%E2%80%93%E2%80%94%E2%80%97%E2%80%98%E2%80%99%E2%80%9A%E2%80%9C%E2%80%9D%E2%80%9E%E2%80%A0%E2%80%A1%E2%80%A2%E2%80%A6%E2%80%B0%E2%80%B9%E2%80%BA%E2%82%AC%E2%84%A2"));

will display a bunch of unicode glyphs from the en-dash to the TradeMark symbol.

The problems with this work around, are the space it takes up in your script, and you have to know the character encoding in utf-8, which I'm guessing most people don't.
All in all this makes scripting with non-ASCII characters/symbols near impossible for most windows users. And that makes writing Euro-friendly scripts hard, not to mention Japanese and other character sets.

[ Permlink | « Hide ]

Nicholaz Beresford added a comment - 28/Sep/07 09:11 AM

This seems to work in the viewers I build. I didn't do anything to fix it, maybe it just depends on the version of Cygwin tool used to create the LSL compiler.

[ Permlink | « Hide ]

Alissa Sabre added a comment - 15/Dec/07 09:55 PM

I noticed that Linden's official 1.18.5.3 viewer handles these non Latin 1 characters properly even on Windows. I tested it on Windows XP SP2.

Can anybody else confirm it?

[ Permlink | « Hide ]

Soft Linden added a comment - 07/Aug/08 11:52 AM

Fixed in 1.20. This only needed a flex upgrade.