Abstract:
A font database includes a plurality of font files each of which stores bitmaps associated with a range of characters. The plurality of font files contains only a single version of a bitmap for each character. In a first embodiment, a plurality of composite font files contain one of more pointers pointing to selected ones of said plurality of font files. In a second embodiment, a rules set responsive to a print request retrieves a desired font file to print a character in accordance with the established rule set.

Description:
TECHNICAL FIELD 
     The present invention relates to the generation of fonts, and more particularly, to the use of composite fonts to minimizing the font storage area for an apparatus using a plurality of different fonts. 
     BACKGROUND OF THE INVENTION 
     With the increasing number of electronic devices that are usable with a wide variety of applications and within a number of markets and countries wherein different languages are used, the amount of storage for numerous types of fonts has become increasingly problematic. Fonts may comprise one of a number of different types. Vector based and synthesized fonts (for example TrueType) may be used for larger characters and do not require a significant amount of storage space for containing the fonts. However, vector based and synthesized fonts do not work very well for smaller characters having a small number of pixels. Instead, bitmap fonts are used for smaller characters wherein each character is handmade at the pixel level. Unfortunately, bitmap fonts require a large amount of storage area, especially in the case of Chinese and Japanese character sets, and even a greater amount of storage area when a variety of styles are required for the different characters such as various point sizes, bolded versus non-bolded characters and italicized versus non-italicized characters. 
     The main problem arising from the use of bitmap fonts comes from the storage requirements which are necessary to store information on a large number of fonts. For example, several hundred kilobytes may be required for just one font. Thus, if each character requires five different point sizes, three different types of bolding and three different types of italics for each character, the storage space necessary for the font can easily take up five to ten megabytes. Since many types of portable electronic equipment may only contain a few megabytes (for example, four megabytes) of flash memory for storage, this type of storage requirement is unacceptable. The only presently known solution is to limit the number of styles in order to save resources, however, this sacrifices the look and appearance of the characters upon a display. Thus, present solutions to this problem must either limit the look of characters provided by display or increase the application complexity in order to make the best use of the available fonts. 
     SUMMARY OF THE INVENTION 
     The present invention overcomes the foregoing and other problems with a method and apparatus for composite font generation. In a first embodiment, a font system includes a plurality of font files, each of which stores bitmaps associated with a range of characters. The plurality of font files only contains a single version of each bitmap for a character. Associated with the plurality of font files are a plurality of composite font files which contain a number of pointers pointing to ones of the plurality of font files. Each font file may have one or more pointers pointing at the font file. 
     In a further embodiment, the font system again includes the plurality of font files each of which stores bitmaps associated with a particular range of characters. The plurality of font files again only contain a single version of a bitmap for a character. A rules set enables the generation of a selected font responsive to a print request. The rules, in response to the print request, select a desired font file based upon the established rules in order to print the requested character. 
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS 
     A more complete understanding of the method and apparatus of the present invention may be obtained by reference to the following Detailed Description when taken in conjunction with the accompanying Drawings wherein: 
     FIG. 1 is an illustration of a first embodiment of the present invention; 
     FIG. 2 is a flow diagram illustrating the method for implementing the embodiment of FIG. 1; 
     FIG. 3 illustrates a second embodiment of the present invention; 
     FIG. 4 illustrates the operation of a font manager configured according to the second embodiment of the invention; and 
     FIG. 5 is a flow diagram illustrating the operation of the embodiment of FIG.  3 . 
    
    
     DETAILED DESCRIPTION 
     In order to support international characters in a variety of sizes, type faces, configurations and alphabets, the Unicode standard is widely used. A font that uses the Unicode standard supports different ranges (alphabets) of characters between 0 and 65535. When implementing fonts in the normal fashion, up to 25% of this range may be utilized. This method of creating a font file involves generating bitmaps for all individual characters and placing them in a large file. If an additional font file is required, (i.e., Arial,  12   p , bold, non-italic) which uses some of the same bitmaps as the previously created font file, the repeated bitmaps would be copied into the new file as well, taking up twice the space. This is, of course, a problem with ranges (alphabets) that are very rarely used or cannot have different styles applied to them. For example, Chinese characters do not need to be bolded or italicized. Likewise, Cyrillic characters included within Asian equipment are not very likely to be used and may only be required in one style, and/or one size. 
     Referring now to the drawings, and more particularly to FIG. 1, there is illustrated the manner in which a composite font database  5  including a number pointers to various font files  15  may be created. The composite font database  5  includes a number of composite fonts  15  which each contain pointers  16  pointing to various font files  20  included within the composite font. Each of the font files  20  include a range of characters each of which is defined by a bitmap. Each of the font files  20  are only stored once within a device in which the composite font database  10  is created. 
     The first composite font file  15 a designated “Arial,  12   p , Regular” comprises pointers  16  to font files  20  for “Arial,  12   p , Regular, Range: Latin”; “Arial,  12   p , Regular, Range: Cyrillic”; and “Arial,  16   p , Regular, Range: Chinese”. The composite font file  15   b  designated “Arial,  8   p , Bold” includes pointers to font files  20  for “Arial,  16   p , Regular, Range: Chinese”; “Arial,  8   p , Bold, Range: Latin”; “Arial,  8   p , Bold, Range: Latin”; and “Arial,  8   p , Regular, Range: Cyrillic”. Finally, composite font file  15   c  designated “Palatino,  10   p , Italics” includes pointers  16  to font files  20  for “Arial,  16   p , Regular, Range: Chinese” and “Palatino,  12   p , Regular, Range: Cyrillic”. Assignment of various font files  20  continues until all desired composite font files  15  are created. Each font file  20  contains only a single version of a bitmap and is stored only once. The composite font files  15  may have multiple pointers directed to a same font file  20 . See, for example, the font file (Arial,  16   p , Regular, Range: Chinese) of FIG. 1 which has three pointers  16  directed to the font file  20   a . Thus, this font file  20   a  must only be stored once rather than three times. 
     A composite font file  15  also may have associated with it a font file  20  having bitmaps for characters larger than the composite font file  15  may expect. For example, the “Arial,  16   p , regular, Range: Chinese” font file  15  pointed to by the “Arial,  8   p , regular” composite font file  20  because “Arial,  8   p  regular, Range: Chinese” does not exist. Thus, when a font size does not exist or is undesirable for a particular character range, the next largest size of font may be used. Whether or not this association is utilized is up to the system designer. In a system that may handle different size characters (dynamic line height) this system should work quite well. 
     Referring now to FIG. 2, there is illustrated a flow diagram of the method for generating a composite font database  5  as illustrated in FIG.  1 . Initially, the bitmaps for each character to be used within the database are determined at step  50 . The bitmaps are divided and stored at step  55  into a plurality of font ranges (font files) wherein each of the plurality of font ranges contains only a single version of each bitmap. Finally, the composite font files, containing a number of pointers, are each generated and stored at step  60 . The font files  20  and composite font files  15  require significantly less storage area than prior art font databases because only a single version of a bitmap is stored but the bitmap may have multiple pointers pointing thereto. The composite font files  15  includes pointers to the various font files stored previously at step  55 . 
     Referring now to FIGS. 3 and 4, there is illustrated an alternative embodiment for generating a self-optimizing composite font. The font files  20  including only a single version of each bitmap for various ranges are stored as described previously with respect to FIG.  1 . The composition rules  70  for generating a font are stored within a system font manager  75 . The composition rules  70  implement the pointers described previously with respect to FIG. 1 responsive to a print request  85 . Therefore, rather than including a number of composite font files  15  as described previously, this embodiment includes rules defining which bitmap should be retrieved from which font file  20  responsive to a print request  85 . The font manager  75  generates the requested fonts in real time responsive to a print request  85  coming from a user or electronic device. The print request  85  includes the character to be printed, and has attached therewith the font name, font size and font style to be printed. Responsive to the this information, the font manager  75  utilizes the composition rules  70  to determine which font file  20  to access for a needed bitmap to generate the character  90  as requested. 
     Referring now to FIG. 5, there is illustrated a flow diagram describing the method performed by the embodiment illustrated in FIGS. 3 and 4. Initially, at step  100 , the composition rules  70  are determined and stored within the font manager  75 . A print request  85  is provided at step  105 , and the font name, size and style are attached to the character request at step  110 . The font manager  75  generates at step  115  the desired character responsive to the attached font size, style and character using the rules  70 . 
     Using the above-described system and method, a database providing a large number of fonts for an electronic device such as a portable computer, personal digital assistant, mobile telephone, etc. may be provided with a greatly decreased storage area necessary for the font database. Thus, a greater variety in the look of fonts can be provided while minimizing required resources and application complexity. 
     The previous descriptions are of preferred embodiments for implementing the invention, and the scope of the invention should not necessarily be limited by this description. The scope of the present invention is instead defined by the following claims.