TweetFollow Us on Twitter

Worldscript
Volume Number:9
Issue Number:10
Column Tag:Worldscript

Related Info: Script Manager

Writing for WorldScript

Essential info about Apple’s Script Manager

By Gary Crandall, DataPak Software

About the author

Gary Crandall (better known as “Gar”) has been developing software for the Macintosh since 1983 and has personally generated over one million lines of code for the 68000-based processor.

Frustrated with TextEdit’s limitations and speed, Gary has been evolving text processing technology for DataPak Software, of which the most recent contribution is Word Solution Engine v2.1, “WorldScript” technology that breaks all barriers of TextEdit.

For the Macintosh, the term script refers to a specific class of characters whose behavior is different from other classes of characters. Put more simply, each unique alphabet on this planet requires a different script, such as Eastern versus Western alphabets.

If you are not already familiar with this aspect of the Macintosh, a script can be confused with language, or some other localization process. But language and scripts are distinctly different.

For example, all Western and European countries use the same script (Roman) even though there are many diverse languages. In the Macintosh, the same set of fonts work for English as well as French, German, Italian, Spanish, etc. as all such languages use the same basic alphabet.

Until recently, the ASCII set as we know it has been sufficient since we have generally excluded non-Roman countries from our software galleries. In a growing new age of world wide economics and an “ever shrinking” globe, the time and demand for additional character sets has arrived.

Unfortunately, the necessary transition can be far more involved than it sounds. Most of us have locked into the “standard” ASCII character set so much in our software design that converting to some new system will not only force virtual re-write, it will force our way of thinking to change.

The Script Manager

The purpose of this article is to offer some insight into an otherwise difficult topic: Apple’s Script Manager. First, let’s clarify some terminology to avoid confusion.

Regardless of what System you are operating, the Script Manager is the portion of the Toolbox that specifically handles non-Roman scripts (non a-z character sets). You can look at Script Manager as an extension of QuickDraw’s text handling functions. This was true in System 6 and is (still) true in System 7.

Some confusion has set in, however, with the release of System 7 and the term WorldScript. By and large, the term WorldScript merely means that the user can switch between multiple scripts without re-starting the machine. While this might be an excellent enhance for multilingual applications, the term WorldScript is really more of a promotional term, from the perspective of a developer, than a technical term.

In System 6, for example, you were generally restricted to a single script. If you ran a Japanese product, you would boot a Kanji System; to revert to a Roman environment, you would re-start from a “blessed” System folder for Roman text, and so on.

With the newer System software, the user is allowed to switch scripts with the same ease as switching fonts or point sizes. Thus, the term “WorldScript.” But that is an enhancement for the user, not the developer; from the programmer’s viewpoint, little has changed. You still need to understand and use the same Script Manager functions, for the most part, as if you were writing for System 6 even if you intend to operate in a WorldScript environment.

Getting Started

This could be personal preference, but I would strongly recommend studying the original Script Manager in Inside Mac Volume 5 before even considering the “WorldScript” information in Volume 6.

For one thing, I find Inside Macintosh Vol 6 generally confusing and convoluted, filled with unnecessary “information” while lacking the basic, important information you really need.

Furthermore, you will eventually realize that the System 7 “enhancements” to Script Manager won’t help you much - or at the very least you will discover the most useful functions are available (and described more clearly) in Volume 5. Again, this is my preference but I am speaking from many months of experience working in this area.

Old Habits

If you decide to go WorldScript with your software, you will need to break some old habits to guarantee compatibility for all present (and future) scripts.

I am using “WorldScript,” in this case, in its true sense: if the user has the ability to choose any script, than you need to be prepared for all the related nuances. If you are programming only for System 6 (where the user is generally stuck with one script), you could get away with a more hard-coding approach (building a “Kanji version,” “Hebrew version” or some other specialized modification of your code). But for true WorldScript, you need to respond correctly to all potential scripts within the same software.

For starters, you can no longer assume a 256-byte character set. In Kanji and other similar scripts, every character is represented by two bytes. You might not think your software will be affected by this, but I have found many unexpected surprises where a single-byte character was assumed.

One subtle case I experienced was an accounting program in which the letters “A,” “L” and “E” represented “Assets,” “Liabilities” and “Expenses.” Of course, there was a resource which defined these letters just in case the product was used in Europe - in which case the “A,” “L” and “E” could be changed to some other localized abbreviations.

What never occurred to me was the product could not possibly be localized for Japan: a Kanji language required two bytes for every character. Unfortunately, there were hundreds of places in the code that examined a single character to determine the account type. So much for “smart” localization!

Another bad habit you will need to break is the left-to-right assumption. Now, everybody knows that left is left and right is right... but not true in Arabic, Hebrew and other similar languages!

Not only does text seem draw from right to left in an Arabic environment, but everything else will be “backwards” as well - at least from our Western point of view. It is all done with mirrors, literally: the left side of your document becomes the right side; left margins are really right margins; “align left” changes its meaning to “align right,” and so on. The bottom line is, you need to stop thinking in terms of left sides and right sides, but rather “side of origin.” Under a Roman convention, the side of origin happens to begin on the left side; other environments originate on the right side.

At the very least, you should design your dialogs and alerts to look nice for either direction. If you have a WorldScript system handy, go into the Control Panel which changes the System direction, and you will see what I am talking about. When you change the System direction to right-to-left, the Dialog Manager will flip all the controls around... UGLY! That is, unless you fix them up to look good in either direction.

Script Manager Pitfalls

The information I am about to give could save you countless hours of grief. I can state this with confidence after completing a new WorldScript revision to Word Solution Engine. There are some very vital and crucial facts missing from both Volume 5 and 6 - and even the Tech Notes - which can throw you for a spin unless you know them in advance.

The first missing fact is the exact relationship and behavior between the current font and the Script Manager functions that return information about characters.

The following point is not made in any Script Manager documentation I have seen, yet it is vital to most functions: you must have the correct script font set in the current GrafPort to receive the correct answer(s) from Script Manager functions.

By “correct script font” I mean the font for which the text will be drawn. If you are asking Script Manager to give you information on text that will be drawn in Kanji, you had better set a Kanji font to be the current font. Otherwise, almost every function that returns information about a character will return the wrong answer.

For example, there is a Script Manager function called CharByte which you can use to determine if a given byte of text is a single-byte character, or if it is the first half or the second half of a double-byte character. When you look over this function, you will be lead to believe that Script Manager can determine the right answer through some magical character decoding of any arbitrary piece of text. Wrong!

The only way Script Manager can give you the correct response to CharByte - at least in a WorldScript environment in which mixed scripts are possible - is to know what font the character is intended for. This is because all 256 values of a byte are “legal” ASCII characters for Roman fonts, whereas for Kanji and other double-byte fonts many of those values denote the upper (or lower) half of a character. Hence, CharByte cannot possibly know which is which without knowing what font the character is intended for.

If you are mixing scripts together (e.g., Roman and Kanji within the same text stream), your problem is a bit more complicated because you need to know what font to set before asking Script Manager to tell you about the character(s). Rather strange, but true: in order to find out what type of characters are in a string of text, you have to already know what type of characters are in the text - or something along that line.

Fortunately, however, in the case of mixed scripts, there is a work-around to the “know before you know” situation. I have found that by setting the “worst case font” I usually get the right answer from CharByte and other similar functions. By worst-case I mean the font which is the most non-Roman. If you know that a piece of text could contain, say, a Kanji character, setting a Kanji font has a tendency to work for all characters in the text even if some of them are Roman.

I found the worst-case-font solution works particularly well for mixed directions, i.e., mixing Roman with a right-to-left script such as Arabic. With such a potential mix, setting the current font to a left-to-right font (Roman) will almost always return bad information, whereas claiming the whole thing is Arabic (even if it is not) will work more consistently.

But the supreme (and correct) solution, if you want to handle mixed scripts with 100% accuracy, is to know what scripts are present and to set the appropriate font for each character interrogation.

The next pitfall you might run into is the character offset mistake.

The function mentioned above, CharByte, and another function called CharType both require a pointer to some text and character position (offset) into that text for which you want information.

If you are anything like me, you will have a tendency to get lazy and always pass “zero” for the character position, and instead just point to a character. Wrong!

Certain scripts, particularly the double-byte variety, require that Script Manager examines a series of bytes in order to determine the characteristic of the byte you are asking about. Unless it can see what bytes come before the character you want to know about, it can return the wrong answer.

For example, the most common use of CharByte is to determine which “half” of a character a given byte of text represents for a double-byte string of text. Suppose you want to know whether the 10th byte of a string is the first or second half of a character - or if it is a single-byte character. If you do not pass “10” for the offset (and instead you merely increment a pointer to the 10th position and pass zero for the offset), Script Manager is not given a chance to examine the first 10 characters to make the correct decision. This point is not made anywhere in the documentation and can be a major cause of unexplained bugs. Here are some examples:

Wrong way:

Boolean IsCharOddByte (char the_char)
 // Returns “TRUE” if char is second half of a Kanji byte
{
 if (CharByte(&the_char, 0) > 0)
 return TRUE;
 else
 return FALSE;
}

Right way:

/* 1 */

Boolean IsCharOddByte (Ptr txt, short char_position)
 // Returns “TRUE” if char is second half of a Kanji byte
{
 if (CharByte(txt, char_position) > 0)
 return TRUE;
 else
 return FALSE;
}

Both of the examples above are an attempt to determine if a character is the second half of a double-byte Kanji character; one example won’t always work.

The first example will often fail because a single character can “look” like a Roman byte; furthermore, an offset of “zero” implies to Script Manager that no way is the character the second half of a Kanji byte.

The second example works because it gives the Script Manager a chance to examine the sequence of bytes and you will always get the right answer.

Note: BOTH examples will fail if the font in the current GrafPort is not a Kanji font.

The Infamous Position “Flip”

One area that can drive you mad - if you are not prepared for it - is the usage of MeasureJust for right-to-left script such as Hebrew or Arabic (MeasureJust is a function that returns consecutive character positions, in pixels, of a given block of text).

You would think that given the same font, style, point size, and even the same text, MeasureJust returns the exact same answer every time.

Wrong! MeasureJust will return a different answer depending on the writing direction setting of the System (right-to-left or left-to-right). Furthermore, the difference(s) will not be what you would expect. Let’s do a quick experiment to illustrate what happens:

 short  char_positions[5];// Holds MeasureJust answers
 
 MeasureJust(text_ptr, 4, 0, char_positions);

The small code sample above is attempting to measure text_ptr which is a series of, say, four Arabic characters. The result will be placed in the char_positions array which will be (supposedly) the physical pixel positions for each character in text_ptr. Here are the various results you will receive:

(1) If System is set for right-to-left, char_positions might look like this:

22, 16, 11, 6, 0

(2) If System is set for left-to-right, char_positions would look like this:

0, 16, 11, 6, 22

What you will conclude is the text is “drawn” differently depending on the System writing direction - but that too is incorrect: Arabic text is drawn the same (right-to-left) regardless of the writing direction. So you will conclude that MeasureJust was designed specifically to drive you crazy.

One solution to this inconsistency is to check for a situation where the two ends are “flipped” as in the second example above. Here is some code that demonstrates how to fix the problem:

/* 2 */

void ReturnActualCharPositions (Ptr text, short text_length, short *array)
{
 GrafPtrcur_port;// Used to check current font
 short  script;  // Used to check current script

 MeasureJust(text, text_length, 0, array);

// So far so good, but I will need to flip the two ends in 
// the array if right-to-left script but left-to-right System

 if (TESysJust() >= 0)  // If left-to-right  {
 GetPort(&cur_port);
 script = Font2Script(cur_port->txtFont); // Gets current script
 if (GetScript(script, smScriptRight)) // If right-left script {
 short  temp;

 temp = array[0];
 array[0] = temp[text_length];
 array[text_length] = temp;
 }
 }
}

Now & The Future

If you are anything like me, it is not only difficult to confront “change,” it is even more difficult to face an alphabet or language that you can’t even read!

However, regardless of your particular present and future text applications, the days of super-localization (made only for U.S. and Europe) are numbered - if not already obsolete. Our Japanese market alone is potentially huge and can no longer be ignored, if for no other reason than economics. Like it or not, you will need to confront WorldScript sooner or later, hopefully sooner: as in any other endeavor in business (or life), the more you know about a subject the more effective you will be.

 

Community Search:
MacTech Search:

Software Updates via MacUpdate

Latest Forum Discussions

See All

Six fantastic ways to spend National Vid...
As if anyone needed an excuse to play games today, I am about to give you one: it is National Video Games Day. A day for us to play games, like we no doubt do every day. Let’s not look a gift horse in the mouth. Instead, feast your eyes on this... | Read more »
Old School RuneScape players turn out in...
The sheer leap in technological advancements in our lifetime has been mind-blowing. We went from Commodore 64s to VR glasses in what feels like a heartbeat, but more importantly, the internet. It can be a dark mess, but it also brought hundreds of... | Read more »
Today's Best Mobile Game Discounts...
Every day, we pick out a curated list of the best mobile discounts on the App Store and post them here. This list won't be comprehensive, but it every game on it is recommended. Feel free to check out the coverage we did on them in the links below... | Read more »
Nintendo and The Pokémon Company's...
Unless you have been living under a rock, you know that Nintendo has been locked in an epic battle with Pocketpair, creator of the obvious Pokémon rip-off Palworld. Nintendo often resorts to legal retaliation at the drop of a hat, but it seems this... | Read more »
Apple exclusive mobile games don’t make...
If you are a gamer on phones, no doubt you have been as distressed as I am on one huge sticking point: exclusivity. For years, Xbox and PlayStation have done battle, and before this was the Sega Genesis and the Nintendo NES. On console, it makes... | Read more »
Regionally exclusive events make no sens...
Last week, over on our sister site AppSpy, I babbled excitedly about the Pokémon GO Safari Days event. You can get nine Eevees with an explorer hat per day. Or, can you? Specifically, you, reader. Do you have the time or funds to possibly fly for... | Read more »
As Jon Bellamy defends his choice to can...
Back in March, Jagex announced the appointment of a new CEO, Jon Bellamy. Mr Bellamy then decided to almost immediately paint a huge target on his back by cancelling the Runescapes Pride event. This led to widespread condemnation about his perceived... | Read more »
Marvel Contest of Champions adds two mor...
When I saw the latest two Marvel Contest of Champions characters, I scoffed. Mr Knight and Silver Samurai, thought I, they are running out of good choices. Then I realised no, I was being far too cynical. This is one of the things that games do best... | Read more »
Grass is green, and water is wet: Pokémo...
It must be a day that ends in Y, because Pokémon Trading Card Game Pocket has kicked off its Zoroark Drop Event. Here you can get a promo version of another card, and look forward to the next Wonder Pick Event and the next Mass Outbreak that will be... | Read more »
Enter the Gungeon review
It took me a minute to get around to reviewing this game for a couple of very good reasons. The first is that Enter the Gungeon's style of roguelike bullet-hell action is teetering on the edge of being straight-up malicious, which made getting... | Read more »

Price Scanner via MacPrices.net

Take $150 off every Apple 11-inch M3 iPad Air
Amazon is offering a $150 discount on 11-inch M3 WiFi iPad Airs right now. Shipping is free: – 11″ 128GB M3 WiFi iPad Air: $449, $150 off – 11″ 256GB M3 WiFi iPad Air: $549, $150 off – 11″ 512GB M3... Read more
Apple iPad minis back on sale for $100 off MS...
Amazon is offering $100 discounts (up to 20% off) on Apple’s newest 2024 WiFi iPad minis, each with free shipping. These are the lowest prices available for new minis among the Apple retailers we... Read more
Apple’s 16-inch M4 Max MacBook Pros are on sa...
Amazon has 16-inch M4 Max MacBook Pros (Silver and Black colors) on sale for up to $410 off Apple’s MSRP right now. Shipping is free. Be sure to select Amazon as the seller, rather than a third-party... Read more
Red Pocket Mobile is offering a $150 rebate o...
Red Pocket Mobile has new Apple iPhone 17’s on sale for $150 off MSRP when you switch and open up a new line of service. Red Pocket Mobile is a nationwide MVNO using all the major wireless carrier... Read more
Switch to Verizon, and get any iPhone 16 for...
With yesterday’s introduction of the new iPhone 17 models, Verizon responded by running “on us” promos across much of the iPhone 16 lineup: iPhone 16 and 16 Plus show as $0/mo for 36 months with bill... Read more
Here is a summary of the new features in Appl...
Apple’s September 2025 event introduced major updates across its most popular product lines, focusing on health, performance, and design breakthroughs. The AirPods Pro 3 now feature best-in-class... Read more
Apple’s Smartphone Lineup Could Use A Touch o...
COMMENTARY – Whatever happened to the old adage, “less is more”? Apple’s smartphone lineup. — which is due for its annual refresh either this month or next (possibly at an Apple Event on September 9... Read more
Take $50 off every 11th-generation A16 WiFi i...
Amazon has Apple’s 11th-generation A16 WiFi iPads in stock on sale for $50 off MSRP right now. Shipping is free: – 11″ 11th-generation 128GB WiFi iPads: $299 $50 off MSRP – 11″ 11th-generation 256GB... Read more
Sunday Sale: 14-inch M4 MacBook Pros for up t...
Don’t pay full price! Amazon has Apple’s 14-inch M4 MacBook Pros (Silver and Black colors) on sale for up to $220 off MSRP right now. Shipping is free. Be sure to select Amazon as the seller, rather... Read more
Mac mini with M4 Pro CPU back on sale for $12...
B&H Photo has Apple’s Mac mini with the M4 Pro CPU back on sale for $1259, $140 off MSRP. B&H offers free 1-2 day shipping to most US addresses: – Mac mini M4 Pro CPU (24GB/512GB): $1259, $... Read more

Jobs Board

All contents are Copyright 1984-2011 by Xplain Corporation. All rights reserved. Theme designed by Icreon.