FIELD OF INVENTION
The present invention relates to a file configuration format that allows easy changes to Font attributes for inclusion in an embedded device. Still further, Mango has invented a font tool wherein the change in font attributes such as height, weight, line gap, etc takes place that are very difficult to modify otherwise, thereby reducing the cycle time of changing font attributes from days to minutes.
BACKGROUND OF INVENTION
Developing new software library routines to deal with strings in multiple character encodings and/or multiple languages may be prohibitive in terms of cost and time. Furthermore, it may be prohibitive in terms of storage space and/or code maintenance to support libraries to handle characters in multiple character encodings and languages.
Some scripts combine characters to form composed characters whose shape is determined by the relative positions of the characters, i.e., the context of the characters. Examples of these "contextual scripts" are scripts for the Arabic, Hebrew, Thai, and all Indie languages.
Each character of a character set has a unique shape which distinguishes it from other characters in the character set, that is, which allows a reader to distinguish the character from other characters and thus unambiguously convey information. The shape assigned to a particular character is referred to as the "glyph" of the character. The English letter 'A\ for example, has a unique glyph which makes it recognizable from other characters.
Glyphs may have a particular style associated with them. That is. an English 'A" may be written in many different styles, such as in a block style or a calligraphic style. However, the style maintains the basic shape of the character such that the glyph is still recognizable as an 'A.' A collection of glyphs sharing a common style is referred to as a "font." Examples of common fonts are Courier, Times Roman, and Helvetica.
A variety of glyph representation schemes exist. A common scheme is a bitmap glyph, or font. In a bitmap font, the glyph of a given character includes a sequence of bits corresponding to an array of pixels on a display screen. Each bit indicates if the corresponding pixel is to be illuminated or not based on the value of the bit. The pixel array has a characteristic width and height. For example, a glyph may be 24 pixels wide and 24pixels high. In this example, 576 bits, or 72 bytes, of storage are required to
Page 2 of 8

store the glyph.
If the glyphs in a font are the same number of pixels in width, the font is said to be a non-proportional font. If the width is variable, the font is said to be a proportional font. Another common glyph representation scheme is an outline font. A property of outline fonts is that they typically facilitate scaling and rotating.
A mobile processes text encoded according to a character encoding and displays the text on screen. The act of processing the image of a character, i.e., the glyph associated with the character, and displaying the character is referred to as "rendering." A rendering program must use font type information, size information, and potentially contextual information in order to properly render a given character in a given script.
Languages which have a relatively large number of characters, pose particular problems in the context of text processing and rendering. Secondly, the amount of memory required to store fonts and transmit fonts may be costly.
Mobiles are a commodity item. Hence, a mobile having multi language application might cost significantly more than a uni-lingual and may not be accepted readily in the market place. Thus, the factor of cost versus performance figures in.
Major components which have a large bearing on its cost are its memory and processor. If multiple languages are supported, particularly if the languages have a large number of characters, a large amount of memory may be required to store the fonts for the languages. More powerful processors provide higher performance of functions such as character lookup and rendering, but at a greater cost.
The constraints of using fonts on an embedded device are that fonts cannot be used directly from the .ttf (or any other PC format) file. They have to be converted into an intermediate format and then read from there. This introduces many steps in the process as a result of which minor changes to font attributes such as height, weight, line gap, etc are very difficult to achieve.

SUMMARY OF THE INVENTION
The problems outlined above are in large part solved by our invention. The present invention deals with a configuration format that allows easy changes to Font attributes for inclusion in an embedded device. Mango has invented a font configuration format that will be used by Mango's font tool in order to change font attributes. This reduces the cycle time of changing font attributes from days to minutes.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 illustrates the steps generally used for font tool and configuration file information in accordance with the present invention.
FIG. 2 is a simplified pictorial illustrating reduction of font height without reducing size of glyphs in accordance with one embodiment of the present invention
FIG. 3 is a simplified pictorial illustrating vertical alignment of glyphs in accordance with another
embodiment of the present invention,
FIG. 4 is a diagram depicting the memory space saving by use of sparse glyphs.
DETAILED DESCRIPTION OF THE INVENTION
In one embodiment, the system comprises tool which is configured to receive text, the characters of which are encoded according to a multi-lingual character encoding standard, "Unicode". Font tool is further configured to process the Unicode text, and render the text for display on any embedded device. The embedded device is configured with an operating environment which accepts language-specific glyph sets to be modularly "plugged in". One or more glyph sets can be plugged in to support one or more languages as desired. Glyphs or glyph sets may be configured in the embedded device along with the application program.
The operating environment running on the embedded device is configured to manage different tasks, such as application programs, which are executed by the embedded device. Preferably, the operating environment includes a Mango Font Engine which interprets code instructions which are processor independent. Preferably, the application program is interpreted by the Mango Font Engine. The Mango Font Engine includes a Unicode encoding engine which includes library functions for manipulating and printing Unicode character strings. The application program calls the Unicode character string functions to perform string manipulations such as determining Unicode string lengths, copying Unicode strings and connecting Unicode strings. The application program also calls string display functions of the Unicode engine.

The Mango Font Engine further comprises a language detector. The Unicode engine invokes the language detector to determine a language associated with a given character of the Unicode string. The Unicode engine uses the language and the font set by the application program to determine which of the one or more glyph sets of the system includes the glyph for the character. The Mango Font Engine further includes one or more rendering engines for rendering glyphs of a given language and font.
Each rendering engine is configured to render strings of characters according to the rendering rules for its particular language and font. For example, a rendering engine for a contextual language knows how to render characters in a string based on the context of each character. Furthermore, a rendering engine may have specific knowledge about the standards of a given region, such as regarding time, date, and currency symbols. Furthermore, a rendering engine must know the direction in which the characters are to be rendered. For example, an Arabic rendering engine would render the characters from right to left, whereas a French rendering engine would render the characters from left to right.
The glyph sets are preferably arranged in a manner conducive to efficient storage and retrieval of the glyphs in the glyph set, according to the characteristics of the language associated with the glyph set. Glyph sets for languages with a large number of characters may be stored and retrieved. Each glyph set has an associated rendering engine. The Unicode engine invokes the appropriate rendering engine to process and render each Unicode string of the text. A rendering engine renders a character by receiving a glyph associated with a Unicode character and populating a pixel map according to the glyph information. A pixel map is a string of bits indicating the state of each pixel in an array of pixels. For example, in the case of a bitmap glyph of a non-contextual language, rendering the glyph includes copying the glyph bit map to the appropriate location in memory. The pixel map may further include other property information, such as color.
The rendering engine processes and renders characters of the string until the rendering engine encounters a character which does not belong to its language If the rendering engine did not process the entire string, the Unicode engine updates the string pointer to point to the next character in the string which was not processed by the rendering engine, invokes the language detector to determine the language associated with that character, and invokes the appropriate rendering engine. The process continues until all the text has been rendered.

Thus, the system maximizes code reusability thus minimizing development and maintenance time and cost by providing the ability to process text including characters in a universal character encoding. The system renders multiple languages by providing pluggable language-specific modules.
FIG 1 illustrates how the Mango Font Tool generates 'C language source files (*.c & *.h files). Step 102 of FIG 1 denotes the generation of source files using few "*.ttf' files of each font (say verdana.ttf, simhei.ttf) by Mango font tool. One can then choose a source height as in step 104, subsequently a destination height as in step 106 , a center offset in step 108 and sparse glyphs in step 110. This generates the output font format, 112. This can finally be used on the embedded device.
FIG. 2 is a simplified pictorial illustrating reduction in font height without reducing size of glyphs (characters). Two attributes allow us to reduce the font height without reducing the glyph size. The first one is pixeLheight_source. This value is used by the font tool to generate in memory glyphs from the font file. The second attribute is pixel_height_destination. This value is used by the font tool to reduce the height of the glyph bounding box generated in the previous steps. For illustrations, if the source height is 40 pixels, then the intermediate glyphs would look as is shown in the Step 202 of Figure 2A.
Now, if the destination height is 30 pixels then the font tool would remove 5 pixels from the top and 5 pixels from the bottom to generate the glyphs at the bottom (Step 204 of Figure 2B). This invention allows the designer to easily customize Personal Computer fonts for use in an embedded device where the line gap need not be as large as that on the Personal Computer.
FIG. 3 illustrates vertical alignment of glyphs. This is determined by the attribute y_center_align_offset. If positive, then the glyphs are moved downwards and if negative then upwards. As shown in the Step 302 of Figure 3A, if y_center_align_offset is given as 10 then the glyphs are moved downwards by 10 pixels (Step 304 of Figure 3B). This invention allows the designer to position the glyps as appropriate for the embedded device.
FIG 4 is a diagram exhibiting the memory space saved by the use of sparse glyphs. In many cases there is a requirement that only few glyphs in the font are to be used. For illustrations, if we wish to use only the digits from 0-9, our invention allows the designer to generate only those many glyphs. This results in saving of space since the unused glyphs are not generated. Supposing a mobile application has a requirement for showing only the digits 0 to 9 in a special font. Other glyphs such as a,b,c are not to be shown. In existing solutions the special font with ALL glyphs would have to be used and that would mean much more space than is necessary (Figure 4A). With Mango's sparse glyphs invention, only those glyphs are stored in memory which is required (Figure 4B). Thus space saving is achieved.

We claim:
1. A method for reducing font height without reducing size of glyphs in an embedded system, said
method comprising the steps of:
a. measuring attribute, pixel_height_source
b. measuring attribute, pixel_height_destination
c. Memory glyph generated from font file using font tool
d. Height of the glyph reduced using (a) and (b).
2. The method of claim 1, wherein the reduction in font size happens at runtime.
3. A method for vertical alignment of glyphs in an embedded system, said method comprising the
step of determination of the attribute y_center_align_offset.
4. The method of claim 3, wherein a positive value of y_center_align_offset shifts the glyphs
downwards.
5. The method of claim 3, wherein a negative value of y_center_aIign_offset shifts the glyphs
upwards.
6. The method of claim 3, wherein the vertical alignment happens at runtime.
7. A method of generating sparse glyphs wherein only those glyphs that are to be used is stored in the memory.