Abstract:
An imaging system includes a processor and memory for storing descriptions of images. Such images include mosaic patterns that recur in a larger image. When the larger image is displayed, the mosaic patterns are tiled to fill defined areas of the larger image. If a description of a mosaic pattern in terms of graphics primitives would occupy more memory than a description of the mosaic pattern in a bit map format, then the processor converts the image description to a bit map format, stores the result in the memory, and releases the portion of the memory formerly used for storage of the graphics primitives. Otherwise, the processor delays such a conversion until the bit map is needed for tiling.

Description:
FIELD OF THE INVENTION 
     Embodiments of the present invention relate to methods of storing image data in memory during image processing and to systems that perform such methods. 
     BACKGROUND OF THE INVENTION 
     A conventional laser printer generally includes a print engine, an input interface for receiving data to be printed, and a processor that supplies data to the print engine in response to the received input data. The processor manages a modest internal memory for buffering input data, for translating input data to provide a signal for the print engine, and for paper jam recovery. The input data conventionally includes instructions conforming to a page description language (PDL), such as PCL printer control language, marketed by Hewlett Packard, or the POSTSCRIPT page description language, marketed by Adobe Systems. PCL and POSTSCRIPT are trademarks of the respective aforementioned companies. Some input data in a PDL format may require temporary storage in the printer to facilitate operation on such input data as a whole. In the process of providing a signal to the print engine, input data in a PDL format is conventionally translated to a bit map format. Data in a bit map format may also require temporary storage in the printer to facilitate producing a scan signal to the print engine. When a portion of an image in a bit map format is needed more than once on the same page, memory management routines conventionally require temporary storage of the repeated bit map data for access at different times. Paper jam recovery is an attractive feature of a printer that operates as a page printer. A page printer prints respective pages on sequential separate sheets of paper. Such a printer maintains a complete description of each page until the sheet for that page exits the printer. If a paper jam should arise before the sheet exits the printer, the page is reprinted as soon as the jam is cleared without the printer receiving again the input data in a PDL format. 
     The market for printers imposes economic constraints that limit the amount of memory available to the processor for the functions discussed above and other communication and image processing tasks. In addition, demand for low cost, high throughput, high resolution page printers continues to increase. A continuous high throughput page printing rate is difficult to achieve with an economically limited memory size. The page printing rate degrades when processing is stopped by a memory-out condition. Such a condition can arise when an excessive amount of data in a bit map format is being retained. The page printing rate may also be degraded when data in a bit map format is discarded (to free memory demanded for other purposes and then recreated when next needed. In this later case, processing time increases to produce the image to be printed. Such processing time directly degrades the page printing rate. 
     The interruption in processing or increased processing described above may have adverse effects on the computer system to which such a printer is connected. For example, an interruption in processing may interrupt network communication between a computer and the printer. Delays in transmission of input data and/or retransmission of incompletely processed input data consumes network resources and computing resources that may otherwise have been effectively applied to other purposes of the computer system. 
     In view of the problems described above and related problems that consequently become apparent in the art of image processing systems, the need remains for methods and apparatus for managing memory used for image processing. 
     SUMMARY OF THE INVENTION 
     An imaging system according to an embodiment of the present invention includes a memory and a processor. The processor performs a method for managing utilization of the memory. The method includes the following steps in any order: (a) forming a decomposition of provided graphic elements where the decomposition includes graphic primitives and the decomposition occupies a first portion of the memory; (b) determining an estimate of a system resource utilization that would be incurred with a step of rendering; (c) determining in accordance with the estimate, whether to postpone performance of the step of rendering; and (d) rendering the graphic primitives to form bit map data that occupies a second portion of the memory, thereby permitting reuse of the first portion of the memory. 
     By forming a decomposition of the image in graphic primitives, an estimate of memory utilization and/or processor utilization may be used to defer rendering when immediate rendering would consequently commit more memory to storing the rendered result or involve more processing time. System performance improves. In a printer such system performance includes increased ability to print complex images, faster page printing rate, and the ability meet such printing performance goals with less memory. 
     When the graphic primitives are of a variety of types, calculating the estimated amount of memory as a sum of a first expression in accordance with a first type and a second expression in accordance with a second type provides a more accurate estimate of system resource utilization, especially memory utilization. 
     In a variation, the step of determining the estimate further includes the following steps in any order: (e) determining an estimated amount of memory for the second portion; (f) forming a difference between a size of the first portion and the estimated amount of memory for the second portion; and (g) if the difference exceeds a predetermined threshold value, proceeding to perform the step of determining whether to postpone; and otherwise determining the estimate in accordance with a processing duration associated with the step of rendering. 
     By determining whether to postpone rendering on the basis of memory utilization, a calculation of processing duration may be avoided for those cases where a difference in memory utilization is significant. 
     Another embodiment according to various aspects of the present invention, provides a printer which includes an interface, a processor, and a print engine. The interface receives a first description of a page to be printed. The first description conforms to a page description language. The processor performs a method that includes the following steps in any order: (a) deriving a second description of a portion of the page from a portion of the first description; (b) assessing a processor resource utilization with respect to deriving from the second description a third description in a bit map format of the portion of the page; (c) deriving the third description when storage of the third description instead of the second description would improve the resource utilization; and (d) deriving scan line data from the third description. The print engine prints the page in accordance with the scan line data. 
     By improving the processor resource utilization, for example, as in reducing memory requirements during processing of a page, a printer with a limited amount of memory can print more complex pages and sustain a faster page printing rate. Use of the present invention in a printer allows memory not used for bit map storage to be used for any other purpose and so generally improves printer capability. 
     In yet another embodiment, a processor is formed on an integrated circuit substrate to perform a method including the following steps in any order: (a) receiving a first description of a tile; (b) deriving a second description of the tile, the second description for storage in a portion of provided memory; (c) assessing a resource utilization with respect to deriving from the second description a third description in a bit map format of the tile; and (d) deriving the third description when storage in the memory of the third description instead of the second description would improve the resource utilization. 
    
    
     BRIEF DESCRIPTION OF THE DRAWING 
     Embodiments of the present invention will now be further described with reference to the drawing, wherein like designations denote like elements, and: 
     FIG. 1 is a functional block diagram of a printer according various aspects of the present invention; 
     FIG. 2 is a data flow diagram of image processing performed by the printer of FIG. 1; 
     FIG. 3 is a sequence diagram of image processing events in an example of image processing according to FIG. 2; 
     FIG. 4 is a chart of representative PDL graphics elements; and 
     FIG. 5 is a chart of representative GL graphics primitives. 
    
    
     DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS 
     According to aspects of the present invention, image processing systems vary in complexity for serving a wide range of applications, such as physical monitoring and measurement, special purpose data analysis, process control, printing, plotting, image recording, and image display, to name a few representative examples. Such systems have an internal functional architecture that includes a processor (e.g., a state machine or a central processing unit), a read/write memory (e.g., RAM) having a limited size, a program storage memory (e.g., ROM) having a limited size, and an imaging output device, for example a memory, a display, or a print engine. These functional elements are coupled in a conventional manner for retrieving processing instructions and/or constants from the ROM, performing image processing operations by the processor, to effect temporary data storage in RAM and/or to produce signals used by the imaging output device. 
     An imaging system according to various aspects of the present invention includes any computer system or peripheral having a processor and memory that cooperate to perform an image processing function. For example, a computer system having a computer, a graphic display, and a network for the exchange of data between the computer and the display may operate as an imaging system exclusively or in addition to other functions. Printer  100  of FIG. 1 is another example of an imaging system, on a smaller scale. A computer (not shown) uses printer  100  as a peripheral. The computer describes an image to be printed using commands of a conventional page description language (PDL) conveyed by signal DATA on line  101 . Printer  100  primarily includes interface controller  106 , bus  113 , formatter  102 , ROM  108 , RAM  112 , print engine controller  116 , and print engine  118  and is suitably constructed according to conventional mechanical, electronic, and software technology, except as described below. 
     An interface controller includes any conventional circuit for performing a messaging protocol in hardware and/or software (or firmware). For example, interface  106  receives into a buffer memory data conveyed by signal DATA on line  101  describing an image; and, by supporting a conventional interface protocol, determines information to be passed to formatter  102  via lines  105 ,  103 , and bus  113 . Interface controller  106  also responds to commands (e.g., related to an interface protocol) from formatter  102  and provides status and control information also by a suitable signal (not shown), also on line  101 . 
     A print engine includes any conventional printing apparatus (e.g., of the type using an ink jet device or a laser printing device) that is responsive to a signal for recording text and/or graphics on media (e.g., paper or photographic film). For example, print engine  118  includes a conventional monochrome or color laser print engine. When print engine  118  includes a raster printing device, data in scan  10  line format is determined by formatter  102  and passed via conventional lines  103 ,  111 ,  115 , bus  113 , and print engine controller  116 , to print engine  118  for printing. 
     A print engine controller may include any digital and/or analog circuitry for supplying data and control signals to a print engine. For example, print engine controller  116  receives from formatter  103  commands and data that direct printing by print engine  118 . Print engine controller  116  provides signals on line  115  to control print engine  118  and responds to status signals from print engine  118  on line  115 . Status information is communicated by print engine controller  116  to formatter  102  in a conventional manner. An alternate print engine controller includes direct memory access (DMA) circuitry that reads data from ROM  108  and/or RAM  112  to be printed and writes status to RAM  112  without intervention by formatter  102 . An alternate formatter includes such DMA circuitry. 
     Memory used in printer  100  includes any combination of conventional read/write and read only memory circuitry and provides storage for variables and software (including fixed data items and program instructions). For example, printer  100  includes RAM  112 , expandable with RAM  114 , for storage of variables; and includes ROM  108 , expandable with ROM  110 . ROM  108  provides economical storage for a large amount of built-in software including fixed data items (e.g. fonts) and programs. Some or all of the built-in software may be stored in a compressed format. Any conventional memory circuitry may be used to implement ROM  108  and  112  including static mask ROM, electrically erasable programmable memory devices, and battery-backed dynamic random access memory devices, to name a few common types. RAM  112  provides storage for data and may include a portion of software in compressed or uncompressed format. In operation, downloaded software from interface controller  106  may be stored in RAM  112  in compressed or uncompressed format. RAM  112  provides temporary storage between any operations of image processing. For example, RAM  112  may store input data received on line  101  in a PDL format, image data in a conventional graphics language (GL) format, image data in a bit map format, and/or page buffers for paper jam recovery. 
     A processor according to various aspects of the present invention may include any digital computer circuit that provides image data in accordance with an assessment of cost associated with storing image data in a selected format. Printer  100  includes a processor that additionally performs the functions of a formatter and may in alternate variations perform the functions of an interface controller and/or print engine controller, as discussed above. A formatter controls and coordinates nearly all functions of a printer and formats received data into scan lines for a print engine. For example, Formatter  102  formats data received from interface controller  106  into scan lines provided to print engine controller  116 . Formatter  102  performs program instructions that have been stored in ROM  108  (or  110 ) or in RAM  112  (or  114 ). In a variation, additional special purpose digital computer circuits may be coupled to bus  113  for additional or improved computational capability, process monitoring, or print engine control. Conventional computing circuits for executing a stored program include microprocessor-based and microcontroller-based circuits of the type conventionally implemented on printed circuit boards or on an application specific integrated circuit (ASIC). In a variation, a processor of the present invention is implemented as an ASIC or ASIC chip set. 
     A method of image processing, according to various aspects of the present invention includes any sequence of operations or combination of multitasking processes that accomplish the functions of a processor as described above. For example, imaging process  200  of FIG. 2, executed by formatter  102 , includes four tasks operating in parallel in response to intertask messages. In a variation, one or more of these tasks may be implemented with a circuit that receives and provides signals to convey information equivalent to intertask messages discussed below. 
     Imaging process  200  includes task  210  for describing a page, task  216  for creating bit map data, task  220  for managing storage of image data, and task  222  for preparing a canvas and providing scan lines to print engine controller  116 . Messages between tasks shown in FIG. 2 may include structures or pointers to structures for example of the type described in Table 1 or may include any other suitable memory utilization as defined in any conventional programming language. 
     For describing a page, task  210  receives input data in a PDL format and determines (primarily from the PDL syntax and/or semantics), among other things, data that represents a tile to be used one or more times in creating the printed image on a page. A tile includes any bounded region of an image. Tiles may have any size and may overlap in a manner that appears to be transparent, opaque, or translucent when printed. A tile may include text and/or graphic imagery. 
     On receipt of data describing a tile, task  210  develops a description of the tile using syntax and semantics of a conventional graphic language. Tile Data includes graphics primitives corresponding to tiles and other aspects of the image for the page. Tile Data is stored in graphics language (GL) format in GL store  214 . The position(s) of each primitive (or group of primitives, for example a tile) are described in Tile Positions passed to task  222 . Exemplary input data (in PCL format), Tile Data information, and Tile Position information are set out below in Table 1. 
     
       
         
               
               
               
             
           
               
                 TABLE 1 
               
               
                   
               
               
                 PCL 
                 Tile Data 
                 Tile Position 
               
               
                   
               
             
             
               
                 //Define a diamond shaped 
                 enum { 
                 struct { 
               
               
                 tile at 
                 trapezoid, 
                 prim* prims; 
               
               
                 //(x,y) = (2000,2000) 
                 rectangle, 
                 primpos* pps; 
               
               
                 ubyte 10 FirstMosaic 
                 Xline, 
                 } tile; 
               
               
                 BeginMosaic 
                 Yline 
                 struct { 
               
               
                 NewPath 
                 } PrimitiveType; 
                 prim p; 
               
               
                 sint 16_xy 2000 2000 Point 
                 struct { 
                 prim* next; 
               
               
                 SetCursor 
                 PrimitiveType pt; 
                 } prims; 
               
               
                 unit16 4 NumberOfPoints 
                 int TopLeftX, 
                 struct { 
               
               
                 ubyte eSint16 PointType 
                 TopRightx, 
                 int XPos; 
               
               
                 LineRelpath 
                 BottomRightx, 
                 int YPos; 
               
               
                 //Embedded Data Follows 
                 BottomLeftX, 
                 primpos* next; 
               
               
                 dataLengthByte 16 
                 } prim; 
                 } primpos; 
               
               
                 sint16_raw* 
                 primpos pp1 = 
               
               
                 (1000 1000 -1000 
                 TopY, BottomY; 
                 {2000, 
               
               
                 1006-1000-1000 1000-1000) 
                   
                 2000}; 
               
               
                 EndMosaic 
                 //Decomposition 
                 primpos pp2 = 
               
               
                   
                 provides two 
                 {1000, 
               
               
                   
                 //graphics primitives: two 
                 3000}; 
               
               
                   
                 //trapezoids, each 
                 tile t1 = 
               
               
                   
                 one defining 
                 { 
               
               
                   
                 //a triangle portion 
                 {prim1, 
               
               
                   
                 of half of 
                 prim2, 
               
               
                   
                 //the diamond shape 
                 null}, 
               
               
                   
                 prim prim1 = 
                 {ppl, 
               
               
                   
                 {trapezoid, 2000, 
                 pp2, 
               
               
                   
                 2000, 3000, 1000, 2000, 
                 null} 
               
               
                   
                 3000} 
                 }; 
               
               
                   
                 prim prim2 = {trapezoid, 
               
               
                   
                 1000, 3000, 2000, 2000, 
               
               
                   
                 3000, 4000} 
               
               
                 //Define a rectangular area 
                 //decomposition provides 
                 primpos pp3 = 
               
               
                 to be 
                 //a rectangle for 
                 {1000, 
               
               
                 //filled with the diamond 
                 each border 
                 1000}; 
               
               
                 shaped 
                 //with thickness is 228 
                 primpos pp4 = 
               
               
                 //tile defined above. 
                 //top border 
                 {8772, 
               
               
                 //top left (x,y) = (1000,1000) 
                 prim prim3 = 
                 1000}; 
               
               
                 //bottom right (x,y) = 
                 {rectangle, 1000, 
                 primpos pp5 = 
               
               
                 (9000,9000) 
                 0, 9000, 0, 1000, 1228}; 
                 {1000, 
               
               
                 ubyte 10 FirstBox 
                 //right border 
                 primpos pp6 = 
               
               
                 SetBrushSource FirstMosaic 
                 prim prim4 = 
                 {1000 
               
               
                 sint16 box 1000 1000 9000 
                 {rectangle, 8772, 
                 1000}; 
               
               
                 9000 BoundingBox 
                 0, 9000, 0, 1000, 9000}; 
                 tile t2 = 
               
               
                 SetPenWidth 228 
                 8772}; 
                 {prim3, 
               
               
                 RectanglePath 
                 //bottom border 
                 prim4, 
               
               
                 Paintpath 
                 prim prim5 = 
                 prim5, 
               
               
                   
                 {rectangle, 1000, 
                 prim6, 
               
               
                   
                 0, 9000, 0, 8772, 9000}; 
                 null}, 
               
               
                   
                 //left border 
                 {pp3, 
               
               
                   
                 prim prim6 = 
                 pp4, 
               
               
                   
                 {rectangle, 1000, 
                 pp5, 
               
               
                   
                 0, 1228, 0, 1000, 9000}; 
                 pp6, 
               
               
                   
                   
                 null}; 
               
               
                   
               
             
          
         
       
     
     In Table 1 row 1, a description of a diamond shaped image is provided first in PCL format as such a description might be received. In the second and third columns, exemplary data structures in the C programming language define the memory utilization for tile data and tile position and give an example of values corresponding to the diamond shaped tile. In the second row, the image description corresponds to a rectangle having stoked borders and filled with the diamond shaped tile of the first row. Each border stroke is represented in the second column as a rectangle. 
     For ease of description, the example of Table 1 is greatly simplified in a number of respects. Table 1 illustrates only one graphic element, namely a stroked rectangle. A page description language may include any number of elements, some examples of which are shown in FIG.  4 . Many page description languages also include bit map image data as an element. In a more typical image definition, the PDL description may contain tens of tile descriptions of a wide mix of element types for a single page. The graphics language may include any number of primitives, some examples of which are shown in FIG.  5 . Many graphics languages also include bit map image data as a primitive. Further, only the simplest representation of a stoked border is set out in Table 1. A representation of borders that meet at a corner may include additional trapezoids, XLines, Ylines, and rectangles for improving the appearance of the corner at various orientations to the pixel grid that defines the image of a page. 
     Decomposition includes any method of representing a graphics element by one or more graphics primitives. Task  210  performs decomposition in any suitable manner as illustrated for example by the second and third columns of Table 1. Each tile description resulting from decomposition is stored in GL store  214 . GL store  214  may be implemented as an allocated portion of RAM  112 . When a tile description has been completed, a GL Ready message alerts task  216 . 
     On receipt of a GL Ready message, task  216  makes an assessment of system resource utilization prior to rendering image data into a bit map format. A system resource includes any limited or budgeted capability of an imaging system, for example the extent of memory allocations, processing durations (e.g., CPU cycles), communication traffic (e.g., on bus  113 ), power consumption, heat generation, etc. Such an assessment may include evaluation of the known state of system resources and may include estimates of system resource utilization associated with tasks yet to be performed. For example, the system resource utilization associated with storage of a particular portion of image data in a GL format includes the size (i.e., number of addresses) of the portion of memory that has been allocated for such storage. The system resource utilization associated with rendering such image data from a GL format into a bit map format may include an estimated memory utilization and an estimated processor utilization. 
     An estimate of memory utilization for bit map storage may be calculated, according to various aspects of the present invention, in accordance with a result of a decomposition. For example, the number of pixels included in a graphics primitive may directly correspond to an amount of memory needed to store a representation of that primitive in a bit map format. When a graphics primitive is defined as a filled image, such an amount may be calculated as a product of the area of the primitive, expressed as an integer number of pixels, and the amount of memory for defining the color and properties (e.g., transparency, translucency) of the filler. Tile Data as discussed above includes geometric points on an X-Y grid having integer grid spacing. Each unit of such a grid corresponds to one pixel. Suitable conventional geometric expressions may be used for each type of graphics primitive to determine its included area. For example, Xlines and Ylines may be defined as having a line weight of one pixel and no included area. Simple text may be defined as fixed pitch character codes so that the area taken up by such text may correspond to the number of character positions of the text as stored in a suitable string. 
     Processing duration in a first variation is estimated as a multiple of the estimated amount of memory for the image data in a bit map format. The factor used in such a multiple is determined from analysis of the instruction execution durations that may be required to write each pixel as bit map data. In a second variation, processing duration estimates compensate for differences between types and sizes of graphics primitives. For example, an estimate may include a linear expression for a class of graphics primitives. Such a linear expression may include a slope and an offset obtained by empirical analysis of average processing duration. For example, image processing durations may be measured for a large number of graphic primitives of varying sizes and types in a battery of tests. An analysis of the results of such testing may reveal groups of graphic primitives having processing duration within convenient ranges. By defining such a group as a class and associating a processing duration range with the class, further testing may reveal other graphic primitives that are members of the class. Any number of classes may be defined. Improved accuracy of the estimate of processing duration may result from defining an increasing number of classes. 
     In a case where several graphics primitives together correspond to a single tile, as for example two trapezoids for the diamond shaped tile discussed above with reference to Table 1, the assessment is determined as a sum of the assessment of each contributing graphics primitive. When graphics primitives of several types are to be combined in one assessment, the assessment is determined as a sum of the respective expressions used for each graphics primitive. 
     The results of the assessment of system resource utilization are provided to task  220  as a Tile Properties message. Such a message may be in any suitable format and may include the size of memory occupied by a particular tile data description in GL store  214 , the amount of memory that may be needed to store image data in a bit map format that corresponds to such tile data, and/or an estimate of processing duration expected to be spent rendering graphics primitives from GL store  214  to form such bit map data. 
     On receipt of a Tile Properties message, task  220  determines in what format the respective tile is to be stored. Such a determination may be made in any manner suitable for conserving a system resource. When utilization of a system resource is avoided or decreased, system resource utilization is said to be improved. For example, in a first variation, memory utilization and processing duration are combined in a weighted sum. If the sum exceeds a predetermined minimum value, the cost in terms of the system resource utilization of immediately rendering a GL format to a bit map format is deferred by postponing rendering. Constants used as weights for such a weighted sum may be determined by empirical methods as discussed above. 
     In a second variation, task  216  first provides only an assessment of memory utilization to task  220 . Task  220 , may determine that the rendering operation may be postponed when memory utilization for the bit map data exceeds a predetermined maximum value. When memory utilization by itself is not determinative, task  220  requests an estimate of processing duration and determines whether to postpone rendering on the basis of a comparison of processing duration to a predetermined maximum. 
     In an alternate variation, task  220  compares the memory utilization for a GL format with the memory utilization for a bit map format. If a difference between the size of the memory allocated for data in a GL format and the amount of memory estimated to be used for corresponding data in a bit map format exceeds a predetermined maximum, rendering is postponed. In a preferred version of such an alternative, if the difference is greater than zero, rendering is postponed because, even if the memory allocated for data in a GL format is freed for other use (e.g., bit map data storage), increased memory utilization cannot be outweighed by processor utilization that may be avoided if rendering were not postponed. Such processor utilization may include for example, generation and dispatching of one or more Create Bit Map message discussed below. 
     When task  220  determines that rendering is to be postponed, the tile description remains stored in GL store  214  in a GL format. Otherwise, a Create Bit Map message is immediately (or shortly) provided to task  216 . Task  216  then renders the GL data by generating image data in a bit map format for the respective tile described in GL store  214 . On completion of rendering, task  216  notifies task  220  with a Bit Map Ready message and stores the generated result in bit map store  218 . The bit map description may occupy an allocated portion of RAM  112 . 
     Because rendering may combine information from several graphics primitives, a conservation of memory utilization may be more likely to occur when several bit map primitives are combined with or without other primitives. This result is readily apparent when primitives overlap in an opaque manner. 
     When a complete page description has been received by task  210 , and all related Tile Position messages have consequently been passed to task  222 , task  222  may begin developing as much of the description of the image to be printed as needed for provision of sequential scan line messages (or signals). Image data in page store  224  is generally in a bit map format. In a preferred variation, the description of the image for an entire page is developed by Prepare Canvas task  222  and stored in page store  224 . In an alternate variation, tiles are added to page store  224  in an order that permits scan line messages to be provided when only a portion of the image for an entire page has been developed. In yet another variation, portions of more than one page (or multiple color planes of one or more pages) are developed and stored in page store  224 . According to the variations just mentioned, provision of scan line messages may begin when all color planes are complete or when a portion of one or more is sufficiently complete. 
     In a variation where tiles are demanded as needed, task  222  responds to Provide Scan Line messages from print engine controller  116 , determines identifiers for tiles that are needed for the respective position of the requested scan line in the image to be printed, and sends one or more Provide Tile messages to task  220 . Task  220  determines, for example by table look up or by the structure of the tile identifier, which format was determined to be economical for storage of the requested tile. For a tile that has been stored in a GL format (i.e., rendering has been postponed until now), manage storage task  220  provides a Create Bit Map message to Create Bit Map task  216 . Task  216  reads GL store  214 , creates tile image data in a bit map format, and stores this data in bit map store  218  in a manner as discussed above. Task  216  then provides Bit Map Ready message to task  220  which relays the Bit Map Ready message to task  222 . Task  222  then retrieves image data for the requested tile from bit map store  218 . On the other hand, when tile storage had been determined to be economical in a bit map format, task  220  immediately responds with a Bit Map Ready message to task  222  and task  222  retrieves image data as discussed above to satisfy its request. Prepare canvas task  222  may then perform any combination of the conventional calculations and image (or tile) processing operations to rotate, position, scale, crop, margin adjust, overlay, fill, edge-enhance, and render as halftone(s) to develop the requested scan line message. 
     Cooperation of tasks  210 ,  216 ,  220 , and  222  may be better understood with reference to a sequence of operations described in FIG.  3 . The diagram is read from top to bottom with the time of particular events indicated on the left. The duration between events is not indicated. Two sequences are illustrated in an order selected for convenience of description. Of course, input data in a PDL format may be of any complexity and consequently image data for consecutive tiles may be in any combination of the formats discussed above. Messages and image data are indicated with the digit ‘1’ or ‘2’ as applicable to a first tile used in the first sequence and to a second tile used in the second sequence. 
     In the first sequence from time T a  to time T i , image data for tile  1  is provided from storage in a GL format. At time T a  task  210  provides a GL Ready message to task  216  with respect to tile  1 . At time T b  task  216  provides a Tile Properties message with respect to tile  1  to task  220 . At time T c  task  222  requests tile  1  by sending a Provide Tile message with respect to tile  1  to task  220 . At time T d  task  220  provides a Create Bit Map message with respect to tile  1  to task  216 . At time T e  and T f  task  216  requests and obtains image data for tile  1  in a GL format from task  210 . As here, messages may be used to accomplish access to GL store  214 ; or, in the variation discussed above, task  216  may have direct access to GL store  214 . At times T g  and T h  Bit Map Ready messages are conveyed from task  216  through task  220  to task  222 . At time T i  task  222  accesses image data for tile  1  in a bit map format from bit map store  218 . In an alternate variation, messages between tasks  222  and  216  are used to provide access to such data. 
     In the second sequence from time T j  to time T s , image data for tile  2  is provided from storage in a bit map format. At time T j  task  210  provides a GL Ready message to task  216  with respect to tile  2 . At time T k  task  216  provides a Tile Properties message with respect to tile  2  to task  220 . At time T l  task  220  provides a Release GL message with respect to tile  2  to task  210 . Task  210  may free storage space allocated in GL store  214  for tile  2  because Manage Storage task  220  has determined that storage in Bit Map store  218  should be used instead. At time T m  task  222  requests tile  2  by sending a Provide Tile message with respect to tile  2  to task  220 . At time T n  task  220  provides a Create Bit Map message with respect to tile  2  to task  216 . At times T o  and T p  Bit Map Ready messages are conveyed from task  216  through task  220  to task  222 . At time T q  task  222  accesses image data for tile  2  in a bit map format from bit map store  218 . In an alternate variation, messages between tasks  222  and  220  are used to provide access to such data. 
     At any time that image data for a tile in a bit map format is no longer needed for canvas preparation or for paper jam recovery, task  222  provides a Release Bit Map message to task  216 . Task  216  may free storage space allocated in bit map store  218  that had been used for the respective tile identified in the message. For example, at times T r  and T s  task  222  provides Release Bit Map messages identifying image data for tiles  1  and  2  respectively. 
     The foregoing description discusses preferred embodiments of the present invention which may be changed or modified without departing from the scope of the present invention as defined in the claims. While for the sake of clarity of description, several specific embodiments of the invention have been described, the scope of the invention is intended to be measured by the claims as set forth below.