Writing Software for Other Scripts
To ensure that your applications are compatible with other scripts,
particularly non-Roman scripts, follow the guidelines presented here as well
Working With Fonts
• Do not hard-code font IDs or sizes. System and application fonts have
different font IDs and sizes on various script systems. If you must, use
a font size of 0; otherwise, let the user choose. 'FOND' IDs 0 and 1
always map to system and application fonts for the system script. Font
size 0 always maps to the default system font size. If the user cannot
select fonts and sizes, use the default values listed above.
• On non-Roman systems, the Chicago font does not have ID 0.
• Do not make assumptions about font sizes. System or application fonts
may be 12 or 18 point, or other sizes.
• Do not make assumptions about menu bar height; call
GetMBarHeight to get the correct value.Special script codes
(smUninterp and smRSymbol) are defined for fonts that contain
characters that should not be treated as normal text, such as menu and
palette symbols. These script codes have their own ranges for defining
'FOND' IDs.
• The non-Roman fonts have always included Roman characters for
compatibility. However, in word processors, you'll find that your
text- processing operations are greatly simplified if you extract the
Roman characters and reassign them to a Roman font.
extract blocks of Roman text in a non-Roman font to deal with them
properly in higher-level runs. Word processors should call
FindScriptRun to decompose text so that it fits in the format run
framework. For an example of extracting blocks of Roman text, see the
figure below.
Extracting blocks of Roman text
menu in word processors, for example, font names should appear in
their own font (and script). First, this lets users know the appearance
of the font. Second, some fonts-like Arabic, Hebrew, and Japanese
fonts-have non-ASCII names that only display correctly in their own
script.
Working With Character Codes
In addition to remembering that the meaning of a character code depends on
the font, keep the following principles in mind:
• The character codes may be 1 or 2 bytes.
• The caret (insertion point) should sit between characters, not bytes
(that is, it should not be inserted between bytes of a 2-byte
character).
• The Delete key should delete entire characters, not bytes.
• Two-byte characters may affect data transmission and reception.
• The arrow keys should move over characters, not bytes.
• A character code should ideally have a unique meaning in a particular
script, although this is not always the case. For example, the Symbol
font is in the Roman range but uses a different character assignment
from the standard Roman character set
Working With Text Direction
When working with scripts that display mixed- directional text, remember
the following guidelines:
• Convert mouse-down events to text offsets correctly, regardless of
Worldwide Development: Guide to System Software for comprehensive
details.
• Right or left alignment of dialog box text and menu items should
depend on TESysJust, a low-memory global variable set by the script
system. Word processors should allow users to set the default line
direction on a paragraph-by-paragraph basis.
• The caret (insertion point) should be displayed where the next
entered character will appear. If the position occurs at a direction-run
boundary, use a dual caret. The high caret, called the primary
caret, should indicate where the next character in the primary line
direction will appear, and the low caret, called the secondary caret,
should indicate where the next character in the opposing line direction
• Highlighting should apply to a contiguous set of characters in memory,
information on highlighting with mixed- directional text.
• The arrow keys should move the caret in the direction the arrow
points, regardless of the text direction, even across direction-run
boundaries.
Synchronizing Keyboards and Fonts
Three rules govern the synchronization of keyboards and fonts in non-Roman
scripts:
• Clicking in text should set the keyboard script to the script of the text.
• Typing a character from the current keyboard should select an
appropriate font.
• Selecting a font should set the keyboard to the script of the font.
Handling Numbers
Some scripts include multiple sets of digits. Applications that handle numbers
should accept these as valid digits (the
Script Manager number utilities routines help you do this). For details,
Development: Guide to System Software for details on the routines.
Identifying Keywords and Tokens
Keyword and token identification should work correctly in all scripts. For
details, see Macintosh Worldwide Development: Guide to System Software.
Possible Printing Problems
If you use the wrong LaserWriter driver for a script system, characters map
incorrectly because the drivers are localized and have different encodings. For
instance, a Turkish system with a U.S. LaserWriter driver might print
unexpected forms instead of the substituted characters in the Turkish font.
State information you need may not be saved in picture comments-for
example, modified width tables are not saved. With System 7.0, parameters
for justified text are now saved.
handling in order to represent text properly. On the screen, this is done by
printing. Hebrew or Arabic text might be reversed because text normally goes
from right to left in those scripts.
Printer drivers require slightly different handling, for two reasons:
For example, the LaserWriter writes directly in PostScript.
• A printer driver might need to format the text for accurate line
layout. In this case, the text needs to be transformed before the driver
performs line layout. If the driver is spooling the text and will replay
the text a second time, the text cannot be transformed a second time
because that would ruin the appearance.
once to spool and once to unwind the spool. The text must be transformed when
spooling so that line layout can be done, but during unwinding, the
trans formation must be turned off completely.
Note that some drivers, such as the LaserWriter, use QuickDraw
to put up status messages on the screen. (The PrintAction procedure allows the
printing properly.)
independent of the particular scripts being used. The printer driver should
call this routine whenever it changes the grafProcs in the printing grafPort.
record and saves the original routine addresses.
system that is currently enabled. Each PrintAction procedure does the tasks
appropriate for its script system. For more information, see "Working With
Print Drivers" in Macintosh Worldwide Development: Guide to System
Referenced by (1):