Abstract:
Font character data is maintained in a cache memory in bit map form. Each character is identified a unique identifier (ID) value. The printer searches the cache memory only by ID value to determine the presence of a character in the cache. Pointer tables are avoided. A list is maintained of characters recently employed by the printer and is arranged so as to enable determination of a ranking of usage among the listed characters in cache. When a new character is requested by the printer, the cache is initially searched to determine if the character is present therein. If the character is found, it is immediately accessed and its identifier is placed at the head of the usage list. Other characters are pushed down in the list. The least recently used character in the list (at the list&#39;s bottom) is removed unless it is being employed in a print action, in which case, a next higher character in the list is examined to determine if it should be removed based upon both usage criteria and requirement for a page being processed.

Description:
FIELD OF THE INVENTION 
     This invention relates to printers that are capable of printing multiple fonts and, more particularly, to a method and apparatus for controlling allocation of cache memory space so as to conserve cache memory size while assuring rapid availability of font data. 
     BACKGROUND OF THE INVENTION 
     Present day print mechanisms, such as ink jet and laser-based printers, have the capability of producing text outputs exhibiting many different font presentations. Character fonts are provided to the print mechanisms via read only memories which store the font data in the form of character outlines. In the case of printers employed for Latin-based languages, font sizes are such as to enable an entire font to be accessed from ROM and to be &#34;rasterized&#34; into a bit map state, ready for printing when called upon by the print mechanism. In prior art printers, tables of pointers are constructed which point to bit map data or outline font data, as the case may be. A table is created for every orientation, point size and data type (i.e. bit map or outline) for every font that has character data in use. Because Latin character codes range between 0 and 255, the table method enables a high performance access technique with a fairly low memory cost for the pointer tables. 
     By contrast, fonts employed for Asian character sets encompass tens of thousands of different characters. The provision of tables of pointers to the font data becomes impractical due to the large amount of memory space which is consumed by the tables (not even considering the memory space required for the font data). Further, because of the large quantity of required Asian characters, the technique of pre-rasterizing the outline font data and maintaining it in bit map form results in extremely large memory sizes. Thus, while the immediate availability of pre-rasterized Asian font data enables high speed printer operation, the cost of achieving such operation is concomitantly high. 
     Accordingly, it is an object of this invention to provide an improved method and apparatus for handling of printer font data. 
     It is another object of this invention to provide a memory management technique which enables high usage font data to be available in the form of bit map data to the printer mechanism. 
     It is yet another object of this invention to control which font data is present in bit map form in a cache memory, based upon recent usage. 
     SUMMARY OF THE INVENTION 
     Font character data is maintained in a cache memory in bit map form. Each character is identified by a unique identifier (ID) value. The printer searches the cache memory only by ID value to determine the presence of a character in the cache. Pointer tables are avoided. A list is maintained of characters recently employed by the printer and is arranged so as to enable determination of a ranking of usage among the listed characters in cache. When a new character is requested by the printer, the cache is initially searched to determine if the character is present therein. If the character is found, it is immediately accessed and its identifier is placed at the head of the usage list. Other characters are pushed down in the list. The least recently used character in the list (at the list&#39;s bottom) is removed unless it is being employed in a print action, in which case, a next higher character in the list is examined to determine if it should be removed, based upon both usage criteria and if the character is required for a page being processed. 
    
    
     DESCRIPTION OF THE DRAWINGS 
     FIG. 1 is a block diagram of a printer embodying the invention hereof; 
     FIG. 2 is a schematic showing of a character data structure in a character cache within the printer of FIG. 1; and 
     FIG. 3 is a high level flow diagram illustrating the method performed by the system of FIG. 1 to carry out the invention hereof. 
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
     Referring to FIG. 1, a printer 10 comprises a central processing unit 12 which communicates with other modules within printer 10 via a bus system 14. A print engine 16 is connected to bus 14 and contains apparatus for providing either ink jet or laser-based electrophotography printing actions. An input/output (I/O) module 18 enables communications with a host processor 20. A read only memory (ROM) 22 contains font outline data and a character caching procedure 23 which implements cache management actions. Random access memory (RAM) 24 provides the main storage facility for printer 10. 
     Within RAM 24 is a character cache 26 and an area 28 that includes both an indication of a current page number just processed and awaiting printing, and the output page number of the page just outputted by print engine 16. RAM 24 further includes a linked character list 20 wherein a most recently used character resides at the top of the list and a least recently used character resides at the bottom of the list. Those skilled in the art will realize that much additional data is contained within RAM 24, but that it is not directly relevant to the invention discussed herein. 
     When printer 10 commences operation, its operating system allocates a fixed size of RAM 24 for use as character cache 26. The size of character cache 26 can be predetermined and set to the needs of the environment. If a Kanji font is contemplated for use, then the size of RAM 24 allocated to character cache 26 is much greater than if the printer is to be employed with a Latin-based language. 
     Once RAM size for character cache 26 is allocated, cache 26 is initialized by the printer&#39;s operating system. The portion of the operating system which performs this function is termed the &#34;personality&#34; of the printer and is the software which places data into character cache 26, requests a search for data or deletes specific data or clears the entire character cache 26. 
     When character cache 26 is not full of data, any cache request from the printer&#39;s personality is honored, size permitting. When character cache 26 is filled, character caching procedure 23 comes into play and takes over in deciding which data to replace when a request is made. 
     Character data is stored in the form shown in FIG. 2. Each character record in character cache 26 includes a character ID field 40 which is a unique identifier that enables a search routine to determine whether the identified character is or is not stored within character cache 26. A further field area 42 includes a page designation that indicates the highest page number of pages being processed within printer 10 which will require character data 44. Character data 44 may be either full character raster data or may be outline data which is yet to be rasterized. It is preferred that the character data in field 44 be fully rasterized data. 
     During a print operation, CPU 12, in conjunction with the printer personality software, places a call for a specific character to be used in the print action. In response, character cache 26 is searched to determine if the requested character is in cache 26. The search is carried out by examining a linked list of character ID structures in character cache 24 to determine if an entry is present with an identical value to the character ID of the character being searched. To conserve search time, character IDs may be distributed into regions in accordance with a hash table. Each hash table entry includes a pointer to a linked list of a span of character IDs in a region. A received character ID is segregated into a region and only that region is searched. 
     If a match is found by the search, a pointer to character cache 26 is returned which indicates the address of the character record. If a match is not found, a null pointer is returned, signifying that the character is not in character cache 26 and must be accessed from font outline data in ROM 22. Next, character caching procedure 23 is called and implements a character replacement algorithm which determines if there is room to put new character data in character cache 26 and if not, to make room in character cache area 26 for the new character data. 
     Certain data structures are maintained to enable character cache procedure 23 to carry out its character replacement algorithm. The current page number just processed by CPU 12 and ready for printing and the output page number just printed by print engine 16 are recorded in RAM area 28. Since the current page has already been processed and is awaiting printing, the character caching procedure adds 1 to the current page number to determine the earliest page being processed by CPU 12. If any character in character cache area 26 is required for a page value lying between the current page number plus 1 to the output page number, the character record is maintained in character cache area 26. 
     A further data structure employed by character caching procedure 23 is doubly linked character list 30 maintained in RAM 24. Linked character list (LCL) 30 comprises a listing of character IDs from the most recently used character to the least recently used character. Each time a character is used, it&#39;s character ID 40 is moved to the top of LCL 30 and all other character ID&#39;s are moved down. Character caching procedure 23 employs LCL 30 to determine which character data is to be removed from character cache 26. 
     Turning to FIG. 3, character caching procedure 23 will be further described. Initially, as shown by decision box 50, the procedure awaits a notification from the printer personality (as executed by CPU 12) that a new character is required. Upon receipt of that indication, character caching procedure 23 determines if the requested character is already present in character cache 26. This determination is made by a search of character ID&#39;s of characters stored in character cache area 26. If a &#34;hit&#34; occurs, the stored character is accessed (box 54) and the character ID of the accessed character is moved to the top of linked character list (LCL) 30 in RAM 24. All other listed characters in LCL 30 are &#34;moved down&#34; one position in the list. The procedure then recycles and waits for the next character requirement to occur. 
     If, as shown in decision box 52, it is determined that the requested character is not present in character cache 26, the memory size required for the requested character is calculated (box 60). That calculated memory size is then subtracted from the unused memory area in character cache area 26 to determine if a positive or negative result occurs. In the event a positive result occurs, decision box 62 determines that room exists in character cache 26 for the new character. 
     The character outline data is then accessed from ROM 22, and the character data is rasterized (including &#34;fill&#34; data) and is stored in character cache 26 (box 64). Next, the new character ID is moved to the top of LCL 30 in RAM 24 (box 66) and the procedure recycles. 
     If insufficient memory (i.e. a negative result) is found in character cache area 26 to accommodate the memory requirements of the new character (decision box 62), a decision must be made as to which character data is to be removed from character cache 26 to make room for the new character data. This decision process commences (decision box 68) by determining whether the least recently used (LRU) character in LCL 30 is required for a page being processed by printer 10. This determination is made using the current page and output page data in area 28 of RAM 24 and comparing that data with the page data in field 42 (FIG. 2) of the LRU character record. 
     It will be recalled that the current page value is the fully processed page that is waiting in the print queue to be printed and that the output page value is the last page number to have been outputting from print engine 16. The current page value is, therefore, incremented by 1 to include any page presently being processed--but not yet ready for placement in the print queue. Assuming that the LRU character in LCL 30 is required for a page being processed, that LRU character is not removed from LCL 30. In such case, the procedure moves to decision box 70 where it determines if there are more characters in LCL 30 and if yes, the next higher character in LCL 30 is examined (box 72) in accordance with decision box 68. The procedure recycles until either an LRU character is found that is not required for a page being processed or no further characters are present in LCL 30. In the latter case, the procedure may increase the cache size allocation (box 74) and recycle back to decision box 62. 
     If it is found that the LRU character is not required for a page being processed (decision box 68), it is removed from character cache 26 (box 75). It is next determined whether the memory area occupied by the removed LRU character (and any previously removed characters) is equal to or greater than the memory required by the new character (decision box 76). If not, an additional LRU character must be removed from character cache 26 to make room for the new character. In such case, the procedure continues through the procedure line including decision box 70, box 72 and decision box 68 until sufficient LRU characters are found which, after removal from character cache 26, &#34;free-up&#34; sufficient memory for the new character. In such case (as shown in box 78), the LRU character (or characters) have been removed from character cache 26 and the rasterized new character is inserted into character cache 26. LCL 30 is then updated by moving the character ID of the new character to the top of LCL 30. The procedure then recycles. 
     As can be seen from the above, this invention (1) stores rasterized font data in a character cache, making the rasterized data immediately available for use in the print process; (2) avoids the need for large tables of pointers to character data by associating each character with a unique character ID to enable associative searching of the character data in character cache 26 to determine the presence or non-presence of a character in character cache 26; and (3) adaptively determines which character data should be removed from character cache 26 based upon a least recently used status and a determination whether a character is required for a page currently being processed by the printer mechanism. These combined features enable a printer to handle large Asian fonts and to make individual characters of an Asian font rapidly available to the print mechanism, while assuring minimal use of memory and adaptive management of a cache wherein recently used character data may be staged. 
     It should be understood that the foregoing description is only illustrative of the invention. Various alternatives and modifications can be devised by those skilled in the art without departing from the invention. For instance, the invention may be applied to other types of print data storage management, such as for character outlines, graphics features, etc. Accordingly, the present invention is intended to embrace all such alternatives, modifications and variances which fall within the scope of the appended claims.