Font and Keyboard Synchronization
Font and Keyboard Synchronization
It is important to distinguish between two kinds of scripts: the font script and
the keyboard script. The font script is the script that corresponds to the font
of the active grafPort (also, the font used for displaying characters). The
keyboard script is the script for keyboard input. It determines the character
input method and the keyboard mapping-that is, what character codes are
produced when a sequence of keys is pressed. The upper half of the next figure
shows an example of font and keyboard synchronization with the user entering
the characters for keisanki when the font script corresponds to the keyboard
script, which is Japanese. The lower half of this figure provides an example of
the characters that are displayed when the user enters the same characters
when the font script does not map to the keyboard script.
Font and keyboard script synchronization
TextEdit incorporates the following concepts for styled text:
If your application calls TEClick, TESetSelect, or TESetStyle to
change the font style or to process a mouse-down event in text as either
an insertion point or a selection, TextEdit alters the keyboard script
to correspond to the font script. This means, for example, that if users
type Arabic text followed by Roman text and click in the Arabic text,
the keyboard changes to Arabic without their changing the keyboard
manually. Similarly, if users click in the Roman text, the keyboard
changes to Roman without their altering the keyboard.
If the selection point is not empty (that is, the value of the selStart
field of the edit record, defined by the TERec data type, does not equal
the value of the selEnd field), then TextEdit uses the font
corresponding to the selStart field to alter the keyboard script. When a
selection point falls on a script boundary, the keyboard is synchronized
to the font of the character preceding the boundary (in backing- store
order).
If your application calls TEKey to input a character and if the
keyboard script is different from the font script at the selection point,
the font script changes to correspond to the keyboard script. If a font
was selected and never used, thus remaining in TextEdit's style scrap
record ( defined by the StScrpRec data type), and if the font script
coincides with the keyboard script, then this font is used. Otherwise,
TextEdit searches through the preceding fonts in the style run table
until it locates a font that corresponds to the keyboard. If one does not
exist, then it uses the application font.
If the font script at the selection point is the same as the keyboard
script, then this font is used.
Note: There is one exception to this behavior: when the insertion point
has been placed in Roman characters from a non-Roman font, the keyboard
script is Roman, and the font and the keyboard remain unsynchronized to
allow the user to enter more Roman characters in the non-Roman font.
If your application uses styled TextEdit and allows users to select fonts,
TextEdit displays text correctly in all scripts. Otherwise, your application
should use the application font as the best default for TextEdit.
TextEdit takes advantage of the Script Manager's handling of double-byte
characters so that they can be displayed with improved accuracy and
consistency. If a double-byte character, such as a Kanji character, is typed,
the first byte is buffered by TextEdit until the second byte is processed, at
which time the character is displayed.
The internal buffer used for a double-byte character is unique to each
edit record. Therefore, if TextEdit buffers the first byte of a double-byte
character in a record and then the TEKey procedure is called on an other
record, the byte remains in the original buffer until TEKey processes an other
byte for that edit record.
When the TEKey procedure is called by a Right Arrow, Left Arrow, or
Backspace keyboard event at a double-byte character, then the selection range
is updated beyond the second byte in order for the caret to move once over the
entire character. TextEdit also depends on the Script Manager routines to
handle double-byte characters correctly with mouse-down events, caret
display, highlighting, and other text-processing functions.