Patent Publication Number: US-2003231326-A1

Title: Method and apparatus for improving information storage using compressed and non-compressed data

Description:
TECHNICAL FIELD  
       [0001] This disclosure relates to segregating compressed and non-compressed data within memory.  
       BACKGROUND  
       [0002] The firmware contained within many printers contains executable software code and font data that is stored within read only memory (ROM). Both the software and the font data are compressed to minimize the size of the ROM required. Upon initiating a power-up sequence, the executable software is extracted from the ROM, decompressed, and transferred to read only memory (RAM) for operation. Similarly, the font data is also extracted, decompressed and transferred to RAM, as needed.  
       [0003] Due to differences in the nature of the executable software and the font data, the compression of the executable software is more effective than is the compression of the font data. As a result, the compression process fails to significantly reduce the ROM space required for storage of font data. Moreover, the decompression process requires time and RAM space to complete, as well as additional RAM space to store the decompressed font data.  
       [0004] In the context of low-cost printers, the failure of compression algorithms to significantly reduce the size of font data, combined with the overhead involved in the decompression process, is a significant cost burden. Accordingly, the cost of manufacturing low-end printers has been difficult to reduce.  
       SUMMARY  
       [0005] Information storage associated within a memory device is improved using a combination of compressed and non-compressed data storage formats. Font data may be stored without compression, thereby reducing the overhead associated with decompression and the need to supply sufficient memory to accommodate the font after decompression. Executable code is compressed for storage. 
     
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
     [0006] The same reference numbers are used throughout the drawings to reference like features and components.  
     [0007]FIG. 1 illustrates an environment within which information storage is improved by using an embodiment of memory having compressed and non-compressed data.  
     [0008]FIG. 2 is a block diagram that illustrates detail of the components contained within the printer embodiment of FIG. 1.  
     [0009]FIG. 3 is a flow chart that describes an embodiment for configuring firmware by which some information is stored in a compressed format, while other information is stored in a non-compressed format.  
     [0010]FIG. 4 is a flow chart that illustrates an embodiment by which both non-compressed and compressed font libraries may be built and located on the ROM.  
     [0011]FIG. 5 is a flow chart that illustrates an embodiment for determining which fonts should be considered frequently or infrequently used, and thereby offers greater insight into the operation of block  402  of FIG. 4.  
    
    
     DETAILED DESCRIPTION  
     [0012] Information storage associated within a ROM, non-volatile RAM (NVRAM) or other non-volatile memory device is improved using a combination of compressed and non-compressed data storage formats. Font data may be stored within the non-volatile memory device, herein after referred to as ROM, without compression, thereby reducing the overhead associated with decompression and the need to supply sufficient RAM to accommodate the font after decompression. Executable code is compressed and moved to the ROM for storage.  
     [0013]FIG. 1 shows a system  100  wherein a printer  102  illustrates an example of improved information storage using compressed and non-compressed formats. The printer communicates with a workstation  104  or other client computer over a network  106 . The printer  102  may be any device containing firmware, such as the exemplary printer shown, a digital copier, a multifunction peripheral or other output device. The network may be a cable, a LAN (local area network), a WAN (wide area network), the Internet or other network topology or technology.  
     [0014]FIG. 2 is a block diagram that illustrates the components contained within an embodiment exemplified by printer  102  of FIG. 1. A processor  202  reads and/or writes to memory, including a ROM  204  and RAM  206 . The processor is in communication with a print engine  208 , which in turn configures data, such as raster, used to drive a print mechanism  210 . The print mechanism may be based on a laser engine or other print technology.  
     [0015] The ROM  204  contains a non-compressed font library  212 , which contains font data and information associated with at least one font in a non-compressed data storage format. For example, Times New Roman font may be stored in a non-compressed data format within the non-compressed font library.  
     [0016] A compressed font library  214  may optionally be included. The compressed font library contains font data and information associated with at least one font in a compressed data storage format. For example, Arial font may be stored in a compressed data format within the compressed font library. Generally, fonts are stored within the compressed font library only where the font is consistently or heavily used, and where resources, including available RAM space, are available for decompression and use of the font.  
     [0017] At least one compressed executable code file  216  is contained in ROM. The executable code file is decompressed upon a printer start-up or power-on sequence, resulting in the executable code file  218 , seen in the RAM device  206 . Execution of the executable code by the processor  202  supports the printer functionality; for example, instructions included within the executable code enable the processor to control operation of the print engine  208  and print mechanism  210 . Additionally, a decompression module  220 , which may be located within the executable code or other location, is configured to decompress the compressed font data  214 , resulting in decompressed font data  222 , which is located in RAM.  
     [0018] A master font  224  is a font that may be varied, by the addition of a font variant, to become a unique font. Thus, one master font and a plurality of font variants can provide the functionality of a plurality of conventional fonts. The master font typically contains some information that is common to all fonts. The font variants include information, such as serifs, that vary among different fonts.  
     [0019] Where the master font is heavily used, it may be contained in a file having a compressed format  224 . Where it is not heavily used, it may be contained within the non-compressed font library  212 . Similarly, heavily used font variants may be stored in the compressed font library  214 ; lesser used font variants may be stored in the non-compressed font library  212 .  
     [0020] Where the master font was stored in a compressed format, it may be decompressed and relocated to a file  228  located in RAM. Similarly, any compressed font variants may be decompressed and located with other decompressed font data  222 . Where the master font, or any font variants, was not compressed, it can be accessed, as needed, from ROM.  
     [0021] The flow chart of FIG. 3 illustrates an embodiment  300  for configuring firmware by which some information is stored in a compressed format, while other information is stored in a non-compressed format. The elements of the embodiment may be performed by any desired means, such as by the execution of processor-readable instructions defined on a processor-readable media, such as a disk, a ROM or other memory device. Also, actions described in any block may be performed in parallel with actions described in other blocks, may occur in an alternate order, or may be distributed in a manner which associates actions with more than one other block.  
     [0022] At block  302 , font data is stored in a ROM memory device without compression. This may include all or part of the available font data, and specifically may include data and information associated with: all fonts, lesser used fonts, and font variants.  
     [0023] At block  304 , executable code is compressed and stored in the ROM memory device. The executable code may be configured for any purpose, such as printer operation, including direction of the print engine and print mechanism.  
     [0024] At block  306 , the compressed executable code, which has been appropriately configured to do so, decompresses and relocates to RAM.  
     [0025] At block  308 , the executable code, which has been appropriately configured to do so, accesses the uncompressed font data in ROM. Alternatively, previously compressed font data (such as from library  214  in FIG. 2) may be accessed from RAM. The font data is thereby available for any need, such as to configure information for transmission to the print engine and print mechanism.  
     [0026] At block  310 , the executable code, which has been appropriately configured to do so, controls printer functionality. This includes such operations as control of the processor, print engine.  
     [0027] The flow chart of FIG. 4 illustrates an embodiment  400  by which both non-compressed and compressed font libraries may be built and located on the ROM. In particular, the embodiment determines which specific fonts should be located within each library. The elements of the embodiment may be performed by any desired means, such as by the execution of processor-readable instructions defined on a processor-readable media, such as a disk, a ROM or other memory device. Also, actions described in any block may be performed in parallel with actions described in other blocks, may occur in an alternate order, or may be distributed in a manner which associates actions with more than one other block.  
     [0028] At block  402 , frequently and infrequently used font data are identified. The size, composition and exact membership of each group is determined somewhat by the size of ROM and RAM available, as well as the size of individual fonts and groups of fonts and the predicted preferences of the user for whom the fonts are being selected. Accordingly, selection of any individual font, and the group within which it is located, may depend on the specific application.  
     [0029] At block  404 , frequently used font data is compressed and stored in ROM, while infrequently used font data is stored in ROM without compression. In particular, the non-compressed and compressed font data may be stored within the non-compressed and compressed font libraries  212 ,  214  of FIG. 2.  
     [0030] At block  406 , the executable code, which has been appropriately configured to do so, decompresses any needed compressed font data and relocates it to RAM.  
     [0031] The flow chart of FIG. 5 illustrates an embodiment  500  for determining which fonts should be considered frequently or infrequently used, and thereby offers greater insight to the operation of block  402  of FIG. 4. The elements of the embodiment may be performed by any desired means, such as by the execution of processor-readable instructions defined on a processor-readable media, such as a disk, a ROM or other memory device. Also, actions described in any block may be performed in parallel with actions described in other blocks, may occur in an alternate order, or may be distributed in a manner which associates actions with more than one other block.  
     [0032] At block  502 , the quantities of RAM and ROM memory available are assessed. The greater the amount of RAM available, the greater the number of fonts which may be considered to be frequently used. Such frequently used fonts may therefore be compressed for storage in ROM and decompressed for operation in RAM without causing a shortage of RAM which would slow printer operation. Alternatively, the sizes of ROM and RAM may be selected based on the expected needs of the fonts required. In a still further alternative, the sizes of ROM and RAM and the number of fonts available may be determined by the overall target cost of the printer or other device.  
     [0033] At block  504 , the code-execution RAM space requirements are determined. The size of the executable code, as well as the size of the space required for data, is considered in the determination. The RAM left over after deduction for space required to perform the code-execution is therefore the most that can be considered to be available for use in the storage of decompressed fonts.  
     [0034] At block  506 , an additional constraint requires that the font data which is compressed for storage in ROM must fit into RAM in a decompressed state without negative impact on the operation of the executable code. This requirement must be made in view of the RAM needed for storage of the executable code and other required data.  
     [0035] In conclusion, information storage associated with low-cost printers is improved using a combination of compressed and non-compressed data storage formats. Font data is stored within a ROM without compression, thereby reducing the overhead associated with decompression and the need to supply sufficient RAM to accommodate the font after decompression. Executable code is compressed, and is stored to the ROM in the compressed format.  
     [0036] Although the disclosure has been described in language specific to structural features and/or methodological steps, it is to be understood that the appended claims are not limited to the specific features or steps described. Rather, the specific features and steps are exemplary forms of implementing this disclosure. For example, while some effort has been made to describe embodiments by which decisions can be made as to which fonts should be compressed and which fonts should not be compressed, some benefit may be derived simply by not compressing one or more fonts, when storing the one or more fonts in ROM. This will result in increased RAM availability, since the decompressed font may be accessed out of ROM. Some gain in RAM is also obtained because decompression is not involved, thereby lessening the RAM requirements of the executable code. Additionally, while one or more embodiments have been disclosed by means of flow charts and text associated with the blocks, it is to be understood that the blocks do not necessarily have to be performed in the order in which they were presented, and that an alternative order may result in similar advantages.