next up previous
Next: Keyboard Input Up: The Design and Implementation Previous: Text Composition


Fonts

The {\sf StrikeFont} class is used for the glyphs of the characters in a group of characters with a few modifications. In the following, we describe these modifications.

Firstly, there are special ``xTable'' objects for the ISO 2022 multi octet character sets and Unicode based character sets. The ISO 2022 multi octet characters, namely GB 2312, JIS X 0208, KS X 1001 have only ``fixed width'' characters so we can avoid storing an array of character offsets; these are calculable by a simple expression.

We have implemented a simple class called {\sf XTableForFixedFont}. This class mimics an array by implementing {\sf at:}. It returns the calculated x position in the glyph {\sf Form}. The glyphs bitmap in the {\sf StrikeFont} can be relatively large for those fonts, but the mechanism simply works.

Unicode character set are split into groups based on the scripts. In the other words, the characters that share the same encoding tag are treated as if a distinct font. We refer to this split font as a ``Unicode-based font''. For a Unicode-based font, we attach another object of class {\sf XTableForUnicodeFont}. The character codes in a Unicode based font may start at a, possibly large, non-zero value. To compact the xTable indexing, the xTable object subtracts the ``base offset'' from the start value and returns the x table value in the array.

In general, multiple encoding tags may be used in a {\sf MultiString}, so the fonts for different encoding tags are switched transparently while scanning the string. To implement this mechanism, there is a class called {\sf StrikeFontSet} added. This class implements all protocols that {\sf StrikeFont} does but actually hold an array of {\sf StrikeFont} that represent a same ``family'' of font for different scripts. When a message is sent to a {\sf StrikeFontSet} with a string and/or a character as arguments, the appropriate {\sf StrikeFont} in it is selected based on the leading char of the character in question and the message is delegated to the {\sf StrikeFont}.

One of the useful by-product of this project is the {\sf TextStyle} that can now handle TrueType fonts, via what we call TrueTypeTextStyle. By taking advantage of an existing TrueType rendering feature, TrueTypeTextStyle renders the bezier data extracted from TrueType fonts, stores the rendered bitmap in a cache and lays the bitmap out on a {\sf Form}. For best anti-aliasing, the cached bitmap is stored as a 32bpp {\sf Form} and rendered onto the destination form by combination rule 34 (pre-scaled alpha-blending). When the scanner sees the TextColor change, the cache is flushed. The cache is also flushed at a full garbage collect occurs.

There is a subclass of {\sf AbstractFont} called {\sf TTCFont} and {\sf MultiTTCFont} that represents this TrueType based font. The difference of {\sf TTCFont} and {\sf MultiTTCFont} is in the cache algorithm they use. For a ``large'' character set, which has more than 256 characters, a {\sf MultiTTCFont} that employs simple LRU based cache algorithm is used. For a small character set, a {\sf TTCFont} that employs fixed table of bitmap, is used. Similar to {\sf StrikeFontSet}, there is a {\sf TTCFontSet} to implement the font switching mechanism.

#. =.tex#;''


next up previous
Next: Keyboard Input Up: The Design and Implementation Previous: Text Composition
Owner 2003-02-08