Polyglot Frontier: Technical Notes

{ filsa.net: Polyglot Frontier - Introduction | Resource Index | Get Involved }

Polyglot Frontier: promoting multi-lingual support for Frontier

Originally published on 7/23/97; 9:33:52 AM

Technical Notes

Things to watch out for when you use Userland's Frontier on a Japanese System.

by Hideaki Iimori (iimori@lib.bekkoame.or.jp)
translated by Philip Suh

[Translators note: the Japanese language sources of this document are available from http://www.bekkoame.or.jp/~iimori/indexProgTips.html Portions of this page will only display properly if you have a Japanese capable browser.]
Userland Frontier is a powerful integrated scripting environment; however, because it was not designed with double-byte code langauges in mind (for example, Japanese), when you use double-byte text (e.g., Japanese text) there are a number of things you should watch out for.
1. Deleting double-byte text.
First, when editing double-byte code in WP text objects or in outlines, the delete key doesn't always erase the text properly. Actually, up until the betas of version 4.0 there was a fatal bug which always crashed in a System error if you tried to use the delete key.
Although the text engine that Frontier uses is quite aware of double byte code, it doesn't correctly "Undo" text that has been entered [in double byte code]. In the current (May 1997) v4.1 Frontier application this no longer cuases a system crash, however, it still acts strangely in some places so it is we can't say that the problem has been fixed.
But even considering that, the only real problem is that selected text can't be deleted with the delete key. If you select the text and use the Edit menu to clear or cut the text there is no problem.
I've been using frontier for so many years now that without realizing it I never even reach for the delete key when I'm using Frontier. :-)
2. The next problem is the handling of the backslash character ("\").
Just like C, in Userland Frontier's Usertalk language the backslash is used as an escape character. The Macintosh uses Shift-JIS encoding for Japanese text, so there are occasions when the second byte of a twobyte character appears as the backslash character. Because of this, characters entered directly into UserTalk scripts get corrupted.
Try this: msg("ï\åvéZ")
The second byte of "ï\" is the backslash ("\") so the Japanese text that is displayed in the window will be corrupted.
As far as workarounds are concerned, the first methods is to change the above script to:
msg("ï\\åvéZ")
Putting another backslash after the problem character compensates for this problem.
The second workaround: The problem results from directly entering double byte code into the script. So rather than putting Japanese text directly into the script, stick it into the odb--in a wp text object or outline-- and gather in the text from there. In Macintosh programming rather than put Japanese text directly into the program it is put into a resource, where afterwards it is easy to change with Res-Edit. Using this same method in Usertalk scripts we can fix the problem of character corruption.
Actually, in appleScript as well the backslash is a special charcter, so in AppleScripts displayed in English, the same problem with Japanese characters occurs.
3. The third problem is related to Date/Time formats.
Not just in Frontier and Usertalk, this is a bug which is often seen in regular programs as well: dates and times expressed in strings can't be processed. Let's try to always display this information using numbers. (In Usertalk, date values of the type created by date.get() and date.set()) If the dates are displays as strings, extracting the information from Japanese or other languages will vary depending on the machine; so unless the the script is set to read the string or the machine is set up properly, it won't work.
To deal with this there is a script that requires the US date/time format. This strategy adds 'itl0' and 'itl1' resources to the Frontier.root file, then, inside the root, then from inside the root coerces the date/time to US formats to execute the workaround.
Okay, the install file has been placed here:
DateTimeFormat.hqx
When you double click on the Installer script, the resources listed below will be added to the Frontier.root. When you want to go back to the orignal root, you should delete these resources (with ResEdit).
Type:'itl0' ID:16384
Type:'itl0' ID:16895
Type:'itl1' ID:16384
Type:'itl1' ID:16895

Site Outline
Previous | Next

Other filsa.net services: Frontier Scripting | Script Archive

This is part of Phil's Frontier Scripting Site.
Osaka, JAPAN
Copyright © 1996-97, Phil Suh. All Rights Reserved.
http://www.filsa.net/frontier/polyglot/Japanese/tech1.html
This page last built on 6/28/99; 11:09:41 PM


Originally published on 7/23/97; 9:33:52 AM Technical Notes Things to watch out for when you use Userland's Frontier on a Japanese System.
	by Hideaki Iimori (iimori@lib.bekkoame.or.jp) translated by Philip Suh [Translators note: the Japanese language sources of this document are available from http://www.bekkoame.or.jp/~iimori/indexProgTips.html Portions of this page will only display properly if you have a Japanese capable browser.] Userland Frontier is a powerful integrated scripting environment; however, because it was not designed with double-byte code langauges in mind (for example, Japanese), when you use double-byte text (e.g., Japanese text) there are a number of things you should watch out for. 1. Deleting double-byte text. First, when editing double-byte code in WP text objects or in outlines, the delete key doesn't always erase the text properly. Actually, up until the betas of version 4.0 there was a fatal bug which always crashed in a System error if you tried to use the delete key. Although the text engine that Frontier uses is quite aware of double byte code, it doesn't correctly "Undo" text that has been entered [in double byte code]. In the current (May 1997) v4.1 Frontier application this no longer cuases a system crash, however, it still acts strangely in some places so it is we can't say that the problem has been fixed. But even considering that, the only real problem is that selected text can't be deleted with the delete key. If you select the text and use the Edit menu to clear or cut the text there is no problem. I've been using frontier for so many years now that without realizing it I never even reach for the delete key when I'm using Frontier. :-) 2. The next problem is the handling of the backslash character ("\"). Just like C, in Userland Frontier's Usertalk language the backslash is used as an escape character. The Macintosh uses Shift-JIS encoding for Japanese text, so there are occasions when the second byte of a twobyte character appears as the backslash character. Because of this, characters entered directly into UserTalk scripts get corrupted. Try this: msg("ï\åvéZ") The second byte of "ï\" is the backslash ("\") so the Japanese text that is displayed in the window will be corrupted. As far as workarounds are concerned, the first methods is to change the above script to: msg("ï\\åvéZ") Putting another backslash after the problem character compensates for this problem. The second workaround: The problem results from directly entering double byte code into the script. So rather than putting Japanese text directly into the script, stick it into the odb--in a wp text object or outline-- and gather in the text from there. In Macintosh programming rather than put Japanese text directly into the program it is put into a resource, where afterwards it is easy to change with Res-Edit. Using this same method in Usertalk scripts we can fix the problem of character corruption. Actually, in appleScript as well the backslash is a special charcter, so in AppleScripts displayed in English, the same problem with Japanese characters occurs. 3. The third problem is related to Date/Time formats. Not just in Frontier and Usertalk, this is a bug which is often seen in regular programs as well: dates and times expressed in strings can't be processed. Let's try to always display this information using numbers. (In Usertalk, date values of the type created by date.get() and date.set()) If the dates are displays as strings, extracting the information from Japanese or other languages will vary depending on the machine; so unless the the script is set to read the string or the machine is set up properly, it won't work. To deal with this there is a script that requires the US date/time format. This strategy adds 'itl0' and 'itl1' resources to the Frontier.root file, then, inside the root, then from inside the root coerces the date/time to US formats to execute the workaround. Okay, the install file has been placed here: DateTimeFormat.hqx When you double click on the Installer script, the resources listed below will be added to the Frontier.root. When you want to go back to the orignal root, you should delete these resources (with ResEdit). Type:'itl0' ID:16384 Type:'itl0' ID:16895 Type:'itl1' ID:16384 Type:'itl1' ID:16895
Site Outline Previous \| Next