S&F Ref: 842229 AUSTRALIA PATENTS ACT 1990 COMPLETE SPECIFICATION FOR A STANDARD PATENT Name and Address Canon Kabushiki Kaisha, of 30-2, Shimomaruko 3 of Applicant: chome, Ohta-ku, Tokyo, 146, Japan Actual Inventor(s): Dixon De Sheng Deng, Edward James Iskenderian Address for Service: Spruson & Ferguson St Martins Tower Level 35 31 Market Street Sydney NSW 2000 (CCN 3710000177) Invention Title: Efficient fillmap merging The following statement is a full description of this invention, including the best method of performing it known to me/us: 5845c(1254993_1) - 1 EFFICIENT FILLMAP MERGING FIELD OF THE INVENTION The current invention relates to page description language (PDL) rendering, and in particular to rendering PDL files of high complexity. 5 RELATED BACKGROUND ART A computer application typically provides a page to a device for printing and/or display in the form of a description of the page, with the description provided to device driver software of the device in a page description language (PDL), such as Adobe@ PostScript@ 10 or Hewlett-Packard@ PCL. The PDL provides descriptions of objects to be rendered onto the page, as opposed to a raster image of the page to be printed. Equivalently, a set of descriptions of graphic objects may be provided in function calls to a graphics interface, such as the Graphical Device Interface (GDI) in the Microsoft WindowsTM operating system, or X- 11 in the UnixTM operating system. The page is typically rendered for 15 printing and/or display by an object-based graphics system, also known as a Raster Image Processor (RIP). A typical printer system comprises a host computer, such as a personal computer (PC), connected to a printer by some interface. Example interfaces include a parallel port, Universal Serial Bus (USB), Ethernet or FirewireTM. In a typical office environment the 20 host computer to printer connection may be over a 10/1 00BaseT Ethernet network that is shared with other users and equipment. In such cases the bandwidth of the network is not exclusively available for host computer to printer data transfer. For this reason it is desirable that the amount of data that is sent from the host computer to the printer, and any data and/or status information sent in the opposite direction, be kept to a minimum. The 25 actual time spent transmitting the description of the page from the host computer to the printer impacts on the overall printing time from a user's perspective. The choice of a particular PDL is therefore a crucial factor in minimising the time taken to transfer the page description from the host computer to the printer. In a PDL-based printer the PDL file that describes the page is delivered over the 30 interface from the host computer. Such a PDL-based printer system requires that the printer itself implement PDL interpretation in the course of generating the pixels for 1236437 vl 842229 - 2 printing. PDL interpretation is a task that requires considerable software and/or hardware resources to perform in a reasonable time. The advantage of a PDL-based printer system is that the amount of data that needs to be transferred over the interface is typically small compared to the corresponding pixel data 5 subsequently generated within the printer. This is especially true as the resolution of the printed page increases. In addition, the overall print time of the system, defined roughly as the time from when the user commands the printing of the page to its final production at the printer, is not particularly sensitive to reductions in interface bandwidth. This is because the majority of the overall printing time is consumed by the interpretation of the 10 description in the PDL and the subsequent generation of pixels within the printer, as opposed to the transfer of the description from the host computer to the printer. In contrast to the system including a PDL-based printer, a system using a host-based printer system architecture divides the processing load between the host computer and the printer in a different manner. Host-based printer systems require the host computer, 15 typically a personal computer, to fully generate pixel data at the resolution of the page to be printed. This pixel data is then compressed in a lossless or lossy fashion on the host computer and is delivered to the printer across the interface. By removing the task of PDL interpretation from the printer to the host computer, the complexity of the printer's role is greatly reduced when compared to that of the PDL-based printer. Since complexity usually 20 translates into cost, the printer for the host-based system can generally be made more cheaply than one that needs to perform PDL interpretation for an equivalent printing speed and page quality. A PDL-based printer must be able to reliably handle PDL input of high complexity. It is not always possible to interpret highly complex PDL input in its entirety prior to pixel 25 generation using the limited memory and processor resources available in a printer system. Consequently, several methods have been utilized to enable PDL printers to process highly complex input PDL jobs prior to final pixel generation. US patent application US20070206012 employs one such method. In this method, a batch of consecutive PDL input objects is converted to a region-based representation 30 known as a fillmap. Overlaying PDL input objects are merged with the region-based batch representation by first scan-converting these new objects to a run-length representation and obtaining the equivalent run-length representation of the region-based batch representation. 1236437 v1 842229 - 3 Merging then occurs on a run-by-run basis, thereby producing a new fillmap which can then act as the background for further overlaying PDL input objects. A drawback of this method is its relatively inefficient run-by-run processing. In particular, it fails to take advantage of the inter-scanline coherence of pixel-aligned regions in the region-based 5 representation. Another method involves dividing a complex PDL input into batches of foreground objects which are scan-converted and composited onto a background bitmap. The resultant bitmap may be compressed and be used as the background bitmap for subsequent foreground object batches. This method requires a large amount of memory to losslessly 10 store the background bitmap. Otherwise, the use of lossy compression introduces compositing errors as each batch of foreground objects is processed. Other similar methods divide the page into strips and batch objects according to these strips, but they suffer the same disadvantages as this method. Yet another approach, discussed in patent US 6049339, merges the outlines of some or 15 all of the input PDL objects into a planar map, whereby each region in the planar map is tagged with objects that are needed to composite the region. Whilst this method removes obscured objects and can reduce the memory required to store the page representation, high precision arithmetic is needed for the method's vector-based calculations. As more object edges are added, the complexity of the method may become excessive for any given 20 hardware platform. The disadvantages of such previous methods include high computational complexity, high memory storage requirements, and potential compositing errors and/or quality loss. Consequently, a need exists for a method for merging batched PDL input objects into a single representation with greater efficiency and quality. Such a method should also 25 produce a compact page representation of good quality, that can be merged with subsequent PDL input object batches, should the need arise. SUMMARY OF THE INVENTION According to one aspect of the invention, there is provided a method of merging at 30 least two overlapping fillmaps into a merged fillmap. The method comprises, for a current scanline within an area of said overlap: 1236437 v1 842229 - 4 dividing each of said fillmaps to a set of one or more spans of contiguous pixels along said scanline, each said span being characterised by a fill sequence; merging said sets of spans to one or more merged spans on said merged fillmap, each said merged span being associated with a fillmap edge; 5 determining, for one merged span, whether a candidate merged edge, corresponding to the fillmap edge a said merged span, references the same fill sequence as that of said merged span; and if this is the case, extending said candidate merged edge with the location of said corresponding fillmap edge of said merged span on the current scanline. 10 According to a second, associated, aspect of the invention there is provided a method of merging at least two overlapping source fillmaps into a merged fillmap, each of the overlapping source fillmaps and the merged filmap comprising a corresponding set of adjacent scanlines. The method comprises; dividing each source scanline of the source fillmaps within an area of an overlap into 15 a respective set of one or more contiguous source spans, each source span comprising contiguous pixels with an identical fill compositing sequence and being associated with a source edge comprising a reference to a starting position and the fill compositing sequence of the source span; obtaining the fill compositing sequence for each merged span by combining the fill 20 compositing sequences of the respective one or more source spans correspondingly positioned in the respective source scanlines, each merged span being associated with a merged edge comprising a reference to a starting position and a fill compositing sequence of the merged span; on at least one of the source fillmaps, identifying at least a pair of touching spans 25 located on adjacent scanlines and having identical fill compositing sequence, the starting positions of the pair of spans defining a demarcation line, 1236437 v] 842229 - 5 comparing the fill composition sequence of at least one first merged span, located on a scanline other than the first scanline of the merged fillmap, with that of a second merged span from a preceding adjacent scanline, the second merged span being chosen so that, on a respective source fillmap, positions corresponding to the starting positions of the first and 5 the second merged spans define a first source demarcation line; and if the fill composition sequence of the first merged span matches that of the second merged span, storing a reference to a starting position of the first merged span in a multiline merged edge that includes reference data of the second merged span. Preferably, if the fill composition sequence of the first merged span does not match 10 that of the second merged span, the method comprises; comparing the fill composition sequence of the first merged span with that of a third merged span from the preceding adjacent scanline, the third merged span being chosen so that, on a respective source fillmap, positions corresponding to the starting positions of the third and a fourth merged spans, the fourth merged span contiguously preceding the first 15 merged span on the same scanline, define a second demarcation line; and if the fill composition sequence of the first merged span matches that of the third merged span, storing information of the first merged span into a multiline merged edge that includes reference data of the third merged span. An electronic apparatus, a computer program and a computer program product 20 configured to perform the method of the first aspect of the invention are also disclosed.. Additional aspects are also disclosed. For example a method is also disclosed for relating a tile of compressed data memory from a first intermediate page representation to that of a second intermediate page representation. The method of relating comprises: identifying a tile associated with a first intermediate page representation comprising 25 of compressed data arranged in a plurality of adjoint tiles; identifying a tile associated with a second intermediate page representation comprising compressed data arranged in a plurality of adjoint tiles; relating the tile associated with the second intermediate page representation with 1236437 vI 842229 - 6 that of the tile associated with the second intermediate page representation; and incrementing a reference count for the first tile; Preferably, the step of relating the tile associated with the second intermediate page representation to that of the first comprises of copying the pointer to memory location of 5 the first tile to that of the second. Also preferably, the step of relating the tile associated with the second intermediate page representation to that of the first comprises the steps of: examining the reference count for the first tile; determining if the reference count has exceeded a threshold; 10 copying the compressed data for the first tile to that of the second; and zeroing the reference count for that tile. In other embodiments, the step of relating the tile associated with the second intermediate page representation to that of the first comprises the steps of: examining the available memory resources; 15 determining if the available memory has dropped below a certain threshold; and copying the compressed data for the first tile to that of the second. The tiles can be associated with partial intermediate page representations. An embodiment is also envisaged wherein no tile for the second intermediate page representation yet exists. 20 BRIEF DESCRIPTION OF THE DRAWINGS One or more embodiments of the invention will now be described with reference to the following drawings, in which: Fig. I is a schematic block diagram of a data processing architecture within which 25 the embodiments of the invention may be practised; 1236437 v1 842229 - 7 Fig. 2A is a block diagram showing an example page containing tiles; Fig. 2B is a block diagram of a tile; Fig. 3 is a schematic flow diagram illustrating the data flow in a fillmap merger according to the preferred embodiment of the invention; 5 Fig. 4 is a block diagram of data processing units associated with the fillmap merger of Fig. 3; Fig. 5A is a representation of an example page display list; Fig. 5B is a second representation of the display list of Fig. 5A; Fig. 6A is a representation of a second example page display list; 10 Fig. 6B is a second representation of the display list of Fig. 6A; Fig. 7 shows the arrangement of batch fillmaps from the example of Fig. 5A; Fig. 8 is a schematic flow diagram of n-way fillmap merging as performed by the Fillmap Merger 350 of Fig. 3, according to the preferred embodiment of the invention; 15 Fig. 9 is a schematic flow diagram of the process of generating a merge-map as used in the method of Fig. 8; Fig. I0A to Fig. 1OC show an example of merge-map generation; Fig. 11 shows the arrangement of resultant fillmap strips for the batch fillmaps from the example of Fig. 5A; 20 Fig. 12 shows the final state of the merge-map for the example of Fig. 5A and the resulting sequence of strip descriptors; Fig. 13 is a schematic flow diagram of the method 860 for generating a sequence of merge and transfer instructions from a merge-map as used in Fig. 8; Fig. 14 is a schematic flow diagram of the method 1330 for generating a new strip 25 descriptor, as used in the method of Fig. 13; Fig. 15 shows the relationship between fillmap dimensions and batch object bounding box sizes for several batch fillmaps; Fig. 16 is a schematic flow diagram of 2-way fillmap merging as performed by the Fillmap Merger 350 of Fig. 3 according to an alternative embodiment of the 30 invention; 1236437 vI 842229 - 8 Fig. 17 is a schematic flow diagram of progressive fillmap merging as performed by the Fillmap Merger 350 of Fig. 3 according to a further alternative embodiment of the invention; Fig. 18 is a schematic flow diagram of the fillmap merging process as used in the 5 method of Fig. 8; Fig. 19 is a schematic data flow diagram illustrating a preferred embodiment of the fillmap region merge processor 420 of Fig. 4; Fig. 20 is a schematic process flow diagram of a method performed by the fillmap region merge processor of Fig. 19; 10 Fig. 21 is a detailed schematic flow diagram of the process of fillmap tile merging 2030 of Fig. 20; Fig. 22 is a detailed schematic flow diagram of the process of fillmap edge merging 2150 used in the method of Fig. 21; Fig. 23 is a detailed schematic flow diagram of a process of fillmap span merging 15 2260 as used in Fig. 22; Fig. 24 is a schematic flow diagram of the fillmap merge optimiser 1920 in Fig. 19; Fig. 25 is an example of a fillmap tile merge. Fig. 26 is a schematic flow diagram of the process 1815 of initialising the transfer processor in Fig. 18; 20 Fig. 27 is a schematic flow diagram of the data copying process between source and destination fillmaps as used in Fig. 26; Fig. 28 is a schematic flow diagram of the pointer copying process between source and destination fillmaps as used in Fig. 26; Fig. 29 is a schematic flow diagram of the process 1845, for accounting for 25 transferred batch fillmaps, used in Fig. 18; Fig. 30 is a schematic flow diagram of the batch fillmap clean up process 1825 after fillmap merging as used in Fig. 18; Fig. 31 is a schematic flow diagram of the fillmap deletion process 3030 used in Fig. 30; 30 Figs. 32A to 32J are examples of fillmap merging optimisations utilising the pointer copy process, the data copy process, and the fillmap deletion processor, shown in time sequence. 1236437 vi 842229 - 9 DETAILED DESCRIPTION INCLUDING BEST MODE The principles of the arrangements described herein have general applicability to merging pixel aligned edge representations of computer graphic object image data for rendering. However, for ease of explanation, the arrangements are described with reference 5 to fillmap representations of pages to be rendered in a pixel rendering system. However, it is not intended that the present invention be limited to the described arrangements. For example, the invention may have application to any arrangement utilising pixel aligned edge representations. Fig. 1 shows a schematic block diagram of a pixel rendering system 100 for rendering 10 computer graphic object images which may be processed by the disclosed method for fillmap merging. The pixel rendering system 100 comprises a personal computer 110 connected to a printer system 160 through a network 150. The network 150 may be a typical network involving multiple personal computers, or may be a simple connection between a single personal computer and printer system 160. 15 The personal computer 110 comprises a host processor 120 for executing a software application 130, such as a word processor or graphical software application. The printer system 160 comprises a controller processor 170 for executing a controlling program 140, a pixel rendering apparatus 180, memory 190, and a printer engine 195 coupled via a bus 175. The pixel rendering apparatus 180 is preferably in the form of an 20 application specific integrated circuit (ASIC) coupled via the bus 175 to the controller processor 170, and the printer engine 195. However, the pixel rendering apparatus 180 may also be implemented in software executed in the controller processor 170. In the pixel rendering system 100, the software application 130 creates page-based documents where each page contains objects such as text, lines, fill regions, and image 25 data. The software application 130 sends a high-level description of the page (for example a PDL file) to the controlling program 140 that is executed in the controller processor 170 of the printer system 160 via the network 150. The controlling program 140 receives the description of the page from the software application 130, and decomposes the graphical objects into edges, levels and fills. These 30 edges, levels and fills are called the first set of primitives. The fill may be a flat fill representing a single colour, a blend representing a linearly varying colour, a bitmap image or a tiled (i.e. repeated) image. 1236437 v1 842229 - 10 The controlling program 140 then further processes this first set of primitives to generate a fillmap and a table of known fill compositing sequences. This fillmap and table of known fill compositing sequences are called the second set of primitives. Generally, throughout this specification and accompanying claims, the expression "fillmap" should be 5 understood as referring to a pixel resolution representation of a set of components of a graphical object derived from a page description. However, with specific regard to the preferred embodiment, the fillmap is a pixel-resolution representation of the first set of primitives, in the sense that every pixel location within the fillmap corresponds to a pixel location within the raster image describing a page and vice versa. In contrast to the raster 10 image representation of a page, each pixel location within the fillmap contains a reference to the fill from which the corresponding pixel location will derive its colour and attribute data. Multiple pixel locations within the fillmap may contain a reference to the same fill. A fill may be a fill compositing sequence of Z-ordered levels, where each level contains 15 attributes such as a fill, together with the opacity of the level; a ROP which determines how to mix the colour and attribute data of this level with other overlapping levels; and the priority, or Z-order of the level. A fill compositing sequence contains a reference to all the objects or levels which may contribute to the colour and attribute data at specified pixel locations. 20 The controlling program 140, executed on the controller processor 170, is also responsible for providing memory 190 for the pixel rendering apparatus 180, initialising the pixel rendering apparatus 180, and instructing the pixel rendering apparatus 180 to start rendering the second set of primitives. The pixel rendering apparatus 180 then uses the second set of primitives to render the 25 page to pixels. The output of the pixel rendering apparatus 180 is colour pixel data, which may be used by printer engine 195. The methods according to preferred arrangement of the invention manage fillmap data in tiles. For the purposes of this disclosure a tile shall refer to a block of N by M pixels, where there are multiple blocks across the width of the page and multiple blocks down the 30 length of the page. Tiles are disjoint and cover the page. Referring to Fig. 2a a tile, for example, 200 will be described. A tile preferably consists of an integer number of 8 x 8 blocks of pixels 202. For example for an A4 page at a printer resolution of 600 dpi, a 1236437 vi 842229 - 11 suitable choice for tile dimensions is M = N = 8. The location of a pixel (X, Y) within a tile, where X, Y are integers, is relative to the upper left hand corner of the tile. Y indexes the tile rows whereas X indexes the offset of a pixel along a tile row. A tile row consists of the set of pixels that span the width of the tile. For example the first pixel 201 in the first 5 tile row occupies pixel location (0, 0), whereas the last pixel 203 in first tile row occupies pixel location (63, 0). Accordingly, the last pixel in the last tile row occupies location (63, 63) 204. Raster tile order refers to processing a tile pixel by pixel tile row by tile row, in sequential order, starting with the first tile row and ending with the last row. Pixel values P[X, Y) within a tile refer to the colour value of a pixel P, located at a location (X, Y). 10 Where the dimensions of a page do not contain an integer number of tiles the page is preferably padded to the requisite size. Typically tiles are processed one by one though they may also be processed in parallel. Referring to Fig. 3, the controlling program 140 executed on processor 170 receives a complex PDL job via the network 150. The PDL interpreter 310, executed as part of 15 controlling program 140, processes the PDL job into graphics primitives for each page to be rendered, which are passed to the display list generator 320. The graphics primitives are divided into batches by display list generator 320 before being decomposed into edges, levels and fills (the first set of primitives) and passed to the pre-renderer 330. The pre renderer 330 executes as part of the controlling program 140 on processor 170 to create a 20 "batch fillmap" for each batch of edges, levels and fills, which are then passed via bus 175 to be stored in fillmap store 340 which is part of memory 190. In the preferred embodiment, when all batch fillmaps associated with a page to be rendered are stored in the fillmap store 340, the fillmap merger 350 fetches the batch fillmaps from the fillmap store 340 via bus 175 and merges the fetched batch fillmaps into a merged fillmap. 25 Merging all batch fillmaps associated with a page ensures obscured objects are not processed during rendering. The merged fillmap produced by fillmap merger 350 is sent via bus 175 to memory 190 to be stored in the spool store 360, ready for rendering by the pixel rendering apparatus 180. In an alternative embodiment, the controlling program 140 may execute the fillmap merger 350 when there is a plurality of batch fillmaps in fillmap 30 store 340. When the fillmap merger 350 is executed before all batch fillmaps associated with a page to be rendered are stored, the merged result will be stored back into the fillmap store 340 as a batch fillmap, replacing the merged batch fillmaps. Such an alternative 1236437 v1 842229 - 12 embodiment will use less memory 190 to store batch fillmaps at the expense of potentially merging graphic objects that will be obscured by another batch fillmap with higher Z-order. Fig. 4 shows the fillmap merger 350 in more detail. The illustrated fillmap merger 350 comprises an Instruction Generation module 410 which generates a sequence of merge and 5 transfer instructions. These instructions are then passed to the Fillmap Merging Processor 420, which then instructs its constituent processors - Tile Transfer Processor 430 and Fillmap Region Merge Processor 440 - to merge batch fillmaps. The Tile Transfer Processor 430 consists of a data copy processor 432 and pointer copy processor 434. The Fillmap Region Merge processor 440 can also instruct the Tile Transfer Processor 430 in 10 certain situations, which shall be described below. It should be appreciated that all elements discussed with respect to Figs. 1, 3 and 4, can be either software-based or hardware components, embedded or otherwise. Fig. 5A is a representation of a display list to be printed. In this figure, each solid horizontal line represents the projection of a display list object onto the x-axis, where the x 15 y plane defines the area of the page to be output. As shown, there are a total of 28 objects in the display list, with object priority, or z level, ranging from z = 0 to z = 27. Where two objects overlap in the x-y plane, the object with the lower z-level is drawn beneath the object with the higher z-level. In Fig. 5A, the object with projection 532 is the bottom-most object in the display list, and here has object 20 priority z = 0. The object with projection 534 has object priority z = 2. The 28 objects of the display list are divided into three batches 500, 510, and 520. Display list batch 500 contains objects with z-levels 0 through 7 inclusive. Display list batch 510 contains objects with z-levels 8 through 19 inclusive, and batch 520 contains objects with z-levels 20 through 27 inclusive. 25 As well as indicating the 'banding' of display list objects by z-order, the shaded regions corresponding to batches 500, 510 and 520 show the x-axis projection of the fillmap produced from each batch. From Fig. 5A, display list batch 500 is used to generate fillmap A, batch 510 is used to generate fillmap B, and batch 520 is used to produce a third fillmap C. 30 The indices 0, 5, 10, 15, and 20 shown at the right of label 595 in Fig. 5A define the tile number, in the x-direction, for the zero-indexed grid of tiles for the page to be printed. The shaded regions A, B and C for display list batches 500, 510 and 520, respectively, show 1236437 v1 842229 - 13 that each generated fillmap has x-dimension equal to an integral number of tiles. Fillmap A is precisely 16 tiles wide, while fillmaps B and C are exactly 13 tiles wide. Note that the dimensions of batch fillmaps are typically equal to the size of the bounding box for constituent display list objects (at output resolution), rounded out to the nearest tile 5 boundary. This detail is further illustrated in Fig. 15. An alternative division of the object display list from Fig. 5A is shown in Fig. 5B. Here, display list batches 500, 540, 550 and 560 give rise to fillmaps A, D, E, and F respectively. Depending on the relative degree of x-y overlap for the four fillmaps produced, this display list division may give a faster merged result than the batched division shown in Fig. 5A. 10 The process of producing batch fillmaps discards the absolute z-level information for display list objects. As described above, fillmaps encode references to fill compositing sequences, where each compositing sequence defines a relative ordering of fills to be composited together. In order to merge fill compositing sequences from fillmaps with x-y overlap, the correct 15 relative ordering of fillmaps must be maintained. One way to achieve this is to assign to each batch fillmap a priority value equal to the z-level of its highest constituent object. Provided display lists are divided into contiguous collections of objects, where all objects in a given batch have z-level either greater than or less than all objects in any other batch, merged compositing sequences will always maintain the correct ordering of object fills. As 20 an example of this, consider Fig. 5A. Here, the three objects with x-axis projections 570, 580 and 590 may (depending on their y extents) overlap in page tile column 15. Where these objects do overlap on the page, assignment of a fillmap priority ensures that the fill for object 590 is laid down 'on top of the fill for object 580, which in turn is laid down on top of the fill for object 570. 25 An alternate scheme for assigning fillmap priorities is to simply increment a counter as each successively 'higher priority' batch is processed. In this way, fillmaps A, B and C would be assigned fillmap priorities 0, 1, and 2 respectively. Figs. 6A and 6B illustrate a different display list to that shown in Figs. 5A and 5B. Here, the display list comprises 29 objects with z-levels ranging from z = 0 to z = 28. In 30 Fig. 6A, none of the fillmaps A, B or C - from batches 600, 610 and 620 respectively overlap in the page x-y plane. Thus, in this example, fillmap merging is a trivial operation: no fill compositing sequence from fillmap A (with fillmap priority 20), B (with fillmap 1236437 v1 842229 - 14 priority 11) or C (with fillmap priority 28) need be merged with another fill compositing sequence. In Fig. 6A, batch 600 is comprised of objects with z-levels both greater than and less than the z-levels of the objects comprising batch 610. As no object from batch 600 5 overlaps an object from batch 610, this display list division is perfectly workable. If, however, any of the objects giving the set of x-axis projections 660 were to overlap with one or more objects from batch 610, such a division would give an incorrect merge result. Fig. 6B divides the object display list of Fig. 6A in another way. As in Fig. 6A, the display list division is non-contiguous, with batch 640 comprised of objects with z-levels 10 both greater than and less than the z-levels of the objects comprising batch 610. Once again, because no display list object from batch 640 can possibly overlap with a display list object from batch 610, this division will produce a correct resultant fillmap. Unlike the example in Fig. 6A, however, this display list division produces fillmaps B and D that do need to be merged. In this case, lower-level merge routines with merge wholly empty 15 (NULL) fillmap tiles from fillmap D with tiles from fillmap B. The size and location of batch fillmaps generated from the example given in Fig. 5A is illustrated in Fig. 7. As shown, the minimally-sized resultant fillmap for the page to be rendered comprises 21 tiles numbered [0, 20] in the x-direction and 24 tiles numbered [0, 23] in the y-direction. Batch fillmap A 710 with fillmap priority 7 occupies tiles [0, 15] in 20 the x-direction and tiles [0, 20] in the y-direction. Batch fillmap B 720 with fillmap priority 19 occupies tiles [7, 19] in the x-direction and tiles [13, 23] in the y-direction. Finally, batch fillmap C 730 with fillmap priority 27 occupies tiles [8, 20] in the x direction and tiles [6, 15] in the y-direction. Fig. 8 is a schematic flow diagram of the overall process 800, carried out by Fillmap 25 Merger 350, of producing a single merged fillmap from a number of pre-generated batch fillmaps. This process is termed n-way merging. The process 800 starts at step 805 and proceeds directly to step 810 where a batch fillmap for a portion of the page display list is generated by Pre-renderer 330. Then, at step 820, the batch fillmap just generated is used to update the location and size of the bounding box for all batch fillmaps not yet merged. 30 The final invocation of this step eventually gives the size and location of the minimally sized resultant fillmap for the page. 1236437 v1 842229 - 15 Following step 820, the method 800 proceeds to step 830, where, if further batch fillmaps must be generated for the page, the method 800 returns to step 810. If the display list has been fully processed, no further batch fillmaps need be generated for the page, and the method proceeds to step 840, where the NULL minimally-sized resultant fillmap is 5 created. This step creates an entirely empty fillmap - that is, with NULL data for all tiles. From step 840, the method 800 proceeds directly to step 850, where the merge-map for the page is generated by Fillmap Merging Instruction Generator 410. The merge-map is then used by Instruction Generator 410 in step 860 to generate the sequence of fillmap merge and transfer instructions for the page. Following step 860, the sequence of merge 10 and transfer instructions is executed by Fillmap Merging Processor 420 at step 870. The overall process 800 then terminates at step 880. Variations of the overall n-way merge process 800 illustrated in Fig. 8 are also possible. Fig. 16 shows one such variation 1600, where, instead of storing an arbitrary number of batch fillmaps, at most two fillmaps need be stored at any one time. This approach - 2 15 way merging - combines each subsequent batch fillmap with the current minimally-sized merge result. This reduces the overall memory requirement of the method, relative to the n-way scheme, but may introduce a high degree of redundant processing where successively generated batch fillmaps have significant x-y overlap. One further variation 1700 of the basic n-way scheme is shown in Fig. 17. This scheme 20 - progressive merging - interleaves batch fillmap generation with fillmap merging. In this approach, batch fillmaps are merged strip-by-strip with the current merge result. Like 2 way merging, this method has a lesser memory requirement relative to n-way merging. Referring once more to the n-way merging scheme illustrated in Fig. 8, the process 850 of producing a merge-map is shown in additional detail in Fig. 9. When a batch fillmap is 25 created, its location is initially expressed in tile units from its parent page origin. Once the minimally-sized resultant fillmap for the page has been created in step 840, a simple vector subtraction allows the locations of batch fillmaps to then be re-expressed in terms of their offset from the position of the resultant fillmap. This procedure is the first step 910 in the process 850 to generate a merge-map for the page. Referring to Fig. 7, this process sets the 30 location of batch fillmaps 710 (A), 720 (B) and 730 (C), to each of (0, 0), (7, 13) and (8, 6) respectively. 1236437 v1 842229 - 16 From step 910, process 850 proceeds to step 920, where a first fillmap for the set of batch fillmaps to be merged is selected. Note that this fillmap need not be the batch fillmap with lowest fillmap priority: for the purposes of process 850, batch fillmaps may be ordered in any manner. Following step 920, the process proceeds to step 930 where the 5 'top entries' for the current batch fillmap are inserted into the merge-map. Referring again to Fig. 7, the 'top entries' for fillmap 720 (also referred to as 720(B)) are obtained from the insertion and removal locations 726 (B.i) and 722 (B.o) at locations (7, 13) and (20, 13) respectively. Similar 'top entry' insertion and removal locations for fillmaps 710 (A) and 730 (C) are shown in Fig. 7 at 716 (A.i), 712 (A.o), 736 (C.i) and 732 (C.o). 10 From step 930, process 850 moves to step 940, where the single 'bottom entry' for the current fillmap is inserted into the merge-map. Referring to Fig. 7, the 'bottom entry' for fillmap 720 (B) is obtained from the removal location 724 (B.o) at location (7, 24). Equivalent 'bottom entries' for fillmaps 710 (A) and 730 (C) are shown at 714 (A.o) and 734 (C.o). Following step 940, the process of constructing a merge-map proceeds to step 15 950. Here, if further batch fillmaps are to be processed, the process 850 proceeds to step 960, where the next batch fillmap in the set to be merged is selected. From step 960, the process 850 returns to step 930. If, at step 950, no further batch fillmaps remain to be processed, process 850 then returns to step 860 at step 970. With reference once again to Fig. 7, the process of generating a merge-map is now 20 illustrated in greater detail. If process 850 processes batch fillmaps from Fig. 7 in reverse priority order, construction of the single resultant merge-map follows the sequence of illustrations given in Figs. 10A, 1OB and 10C. The state of the merge-map after processing each of the three batch fillmaps is shown in Figs. 10A, 10B and 1OC at labels 1000, 1020 and 1040 respectively. 25 Referring to Fig. 10A, selection of fillmap 730 (C) leads to insertion of fillmap top entries 1002 and 1004. Insertion of the corresponding bottom entry 1006 then follows. Note that all fillmap entries are inserted in strict order of increasing x co-ordinate. Thus fillmap entry 1002 (with x co-ordinate 8) is inserted into the merge-map before fillmap entry 1004 (with x co-ordinate 21). 30 Note also that the head entry for any merge-map row defines the y co-ordinate of the following row entries. Thus entry 1002, corresponding to fillmap insertion location C.i, 1236437 v1 842229 - 17 has effective tile co-ordinates (8, 6). The head entry for the first row of the merge-map in state 1000 is shown in Fig. 10A at label 1010. Head entries are themselves arranged in an ordered list of increasing y co-ordinate. Head entry 1015, with y co-ordinate 16, is thus linked after head entry 1010. 5 Selection and processing of fillmap 720 (B) leads to insertion of row head entries 1030 and 1035, top entries 1022 and 1024, and bottom entry 1026 from Fig. 10B. The cumulative state of the page merge map after this is shown at label 1020. Finally, selection and processing of fillmap 710 (A) leads to insertion of row head entries 1050 and 1055, top entries 1042 and 1044, and bottom entry 1046 from Fig. 10C. 10 The overall state of the page merge map following this is shown at label 1040. Fig. 12 shows an enlarged view of the final state of the merge map 1040. The six row entries shown define a total of five bands, or strips, to be used for merging. These are, in order, resultant fillmap strips [0, 5], [6, 12], [13, 15], [16, 20], and [21, 23], each being denoted by its first and last tile row (y) co-ordinate. Fig. 11 shows these five strips 15 superimposed on the merged fillmap from Fig. 7. Referring now to Fig. 11, each fillmap strip comprises one or more separate rectangular regions. The contents of each region are constructed from some combination of batch fillmaps A, B, or C from Fig. 7, or are empty regions. In Fig. 11, regions 1112, 1150, 1146 and 1154 are all empty regions. Regions 1110, 1120, 1130, and 1140 contain tiles from 20 fillmap A only. Similarly, regions 1124 and 1138 in the resultant merged fillmap contain tiles from fillmap C only, while regions 1144 and 1152 contain tiles only from fillmap B. For the resultant fillmap, destination tiles in each of these regions may be directly copied, or else referenced, from the appropriate batch fillmap. Remaining regions are defined by the combination of two or more batch fillmaps. For 25 example, in strip [6, 12], region 1122 is defined by the combination of fillmaps A and C. From strip [13, 15], region 1132 sources tiles from fillmaps A and B. Region 1134 from the same strip sources tiles from fillmaps A, B, and C, while region 1136 combines fillmaps B and C only. Like region 1132, region 1142 from the following strip [16, 20] combines tiles from filmaps A and B. 30 Returning once more to Fig. 12, the association between the regions shown in Fig. 11 and the combinations of batch fillmaps from Fig. 7 is shown in the five strip descriptors 1236437 v1 842229 - 18 1200, 1210, 1220, 1230 and 1240. Each strip descriptor encodes the starting x co-ordinate, in tile units, for each of the regions within the strip, together with an ordered stack of one or more batch fillmaps to be merged for each region. Empty regions are specially encoded, as for region 1112. 5 Generation of each successive strip descriptor uses the previous strip descriptor together with the current merge-map row. For example, strip descriptor 1210 from Fig. 12 is constructed from strip descriptor 1200 and merge-map row 1010. Similarly, strip descriptor 1220 is constructed from descriptor 1210 and merge-map row 1030. The first strip descriptor 1200 is constructed from merge-map row 1050 and the empty strip 10 descriptor 1280. Note that, for any page, the empty descriptor always contains two entries. The first of these, at x = 0, encodes a NULL fillmap stack. NULL stacks are indicated by the "~" character in Fig. 12. The second entry encodes a special INVALID entry, indicated in Fig. 12 by the "#" character. The second entry for the empty descriptor is always at x = M, with 15 M equal to the width, in tiles, of the minimally-sized resultant fillmap. In Fig. 12, for each strip descriptor, the dashed lines between the stacks of fillmaps to be merged denote either a merge instruction, a transfer instruction, or a NULL operation. A merge instruction is so named because the region defined by the strip descriptor at that point contains two or more fillmaps to be merged. A transfer instruction is so named 20 because only a single fillmap need be transferred, or copied, for the region defined by the strip descriptor at that point. Thick dashed lines in Fig. 12 (at label 1250, for example) denote fillmap merge instructions. Other dashed lines represent either transfer instructions (at label 1260, for example), or else NULL operations (at label 1270). Note that a NULL operation exists for every empty region in the resultant fillmap. 25 The merge and transfer instructions for the collection of strip descriptors define the set of instructions executed in step 870 from Fig. 8. A more detailed explanation of the method of generating these instructions (step 860 from Fig. 8) is illustrated in Figs. 13 and 14. Fig. 13 shows the method 860 of iterating through the ordered list of K merge-map rows 30 to generate each of K-1 strip descriptors. The method 860 starts at step 1310 where the first merge-map row is selected. The method 860 then proceeds to step 1320 where the empty strip descriptor is selected. Thereafter, the method 860 proceeds to step 1330 where 1236437 v1 842229 - 19 a new descriptor is generated. From step 1330, the method 860 selects the next row in the merge-map at step 1340. From step 1350, the method 860 then terminates at step 1360 if the selected row is the final row in the merge-map. Otherwise, the method 860 proceeds to step 1370 where the just generated strip descriptor is selected. The method then returns to 5 step 1330. The method 1330 of generating a strip descriptor from a previous descriptor and a merge-map row is shown in Fig. 14. The method 1330 starts at step 1410 where several variables for the method are initialised. The pointer variable MP is used to traverse the ordered fillmap entries in the input merge-map row while a second pointer variable SP is 10 used to traverse the entries in the input strip descriptor. A third pointer variable DP is used to address and link entries in the output strip descriptor. Two list variables are also initialised at step 1410. The first of these, ADD_LIST, records a list of fillmap insertion entries while the second, DELLIST, records a list of fillmap deletion entries. From step 1410, the method 1330 proceeds to step 1420. If the pointer variable MP is 15 non-NULL and the x-position of the MP referenced fillmap entry is less than or equal to the x-position of the SP referenced fillmap stack, the method 1330 proceeds to step 1450. Otherwise, the method 1330 proceeds to step 1430, where the SP-referenced fillmap stack is copied to a variable STACK and processed according to Pseudocode 1: for all entries in DELLIST as FILLMAPENTRY 20 { remove FILLMAPENTRY from STACK if STACK.x >= FILLMAPENTRY.o.x - 1 (top entry only) remove FILLMAPENTRY from DELLIST 25 } for all entries in ADDLIST as FILLMAPENTRY insert FILLMAPENTRY to STACK if STACK != DP referenced fillmap stack link STACK and update DP 30 Pseudocode 1 (step 1430) 1236437 vi 842229 - 20 From step 1430, the method 1330 proceeds directly to step 1440, where the pointer variable SP is advanced to the next fillmap stack in the strip descriptor. If, at step 1420, the pointer variable MP is NULL, or if the x-position of the MP referenced fillmap entry is less than or equal to the x-position of the SP referenced fillmap 5 stack, the method proceeds to step 1450. Here, either ADDLIST or DELLIST are amended according to Pseudocode 2: if MP referenced fillmap is in ADDLIST delete fillmap from ADDLIST else 10 { if MP referenced fillmap entry is an insertion entry add fillmap to ADDLIST else 15 add fillmap to DELLIST } Pseudocode 2 (step 1450) With either fillmap transition list updated, the method 1330 then proceeds from step 1450 to step 1460. Here, if the x-position of the MP referenced fillmap entry is less than 20 the x-position of the SP referenced fillmap stack, the method 1330 proceeds to step 1470, where a further test is performed. If, at step 1470, the x-position of the DP referenced fillmap stack is not equal to the x-position of the MP referenced fillmap entry, processing then continues at step 1480. Otherwise, processing proceeds from step 1470 directly to step 1490. 25 At step 1480, the DP referenced fillmap stack is copied and linked to the current DP position. Step 1480 also sets the x-position of the copied stack to the x-position of the MP referenced fillmap entry. The pointer variable DP is then advanced to the location of the new fillmap stack. Processing then continues at step 1490. At step 1490, the DP referenced fillmap stack is modified according to Pseudo code 3: 30 if MP referenced fillmap entry is an insertion entry insert fillmap to DP referenced fillmap stack 1236437 v1 842229 -21 else remove fillmap from DP referenced fillmap stack Pseudo code 3 (step 1490) From step 1490, processing then moves to step 1492, where the pointer variable MP is 5 advanced to the next fillmap entry in the merge-map row. Step 1492 may also be performed directly following step 1460 if, at step 1460, the x-position of the MP referenced fillmap entry is greater than or equal to the x-position of the SP referenced fillmap stack. From step 1492 or step 1440, method 1330 proceeds to step 1494, where a check is made to see if the merge-map row has been fully traversed. If this is the case, the pointer 10 variable MP is NULL, and method 1330 then performs an additional check at step 1496. Otherwise, if further merge-map row entries remain to be processed at step 1494, the process 1330 returns to step 1420. At step 1496 the process 1330 determines if the strip descriptor has been fully traversed. If this is the case, the pointer variable SP is NULL, and the method 1330 proceeds directly 15 to step 1498. At step 1498, the method 1330 returns to step 1340 from Fig. 13. The method 1330 of generating a new strip descriptor is now illustrated using the example of Fig. 12. First, consider strip 1200, constructed from merge-map row 1050 and empty strip descriptor 1280. Step 1410 from method 1330 sets variables as follows: MP -> A.i(0) 20 SP -> ~(0) DP -> NULL ADDLIST = NULL DELLIST = NULL As MP.x = 0 <= SP.x = 0, step 1420 is followed by step 1450, where A is assigned to 25 ADD_LIST, giving: ADDLIST -> A Next, at step 1460, control passes directly to step 1492, as MP.x = 0 < SP.x = 0 evaluates to FALSE. Here, the pointer variable MP is advanced such that: MP -> A.o(16) 1236437 v1 842229 - 22 As merge-map row 1050 is not yet exhausted, control then returns from step 1494 to step 1420. On this iteration, MP.x = 16 <= SP.x = 0 evaluates to FALSE at step 1420. Thus, control passes to step 1430, where a copy of the NULL fillmap stack (-) is made. The 5 copied stack is then augmented with fillmap A, thereby giving: DP -> A(O) At step 1440, the pointer variable SP is advanced such that: SP -> #(21) Once again, at step 1494, the merge-map is not yet exhausted, and so control returns to 10 step 1420. On this iteration, MP.x = 16 <= SP.x = 21, and so control passes to step 1450. Here, because the MP referenced fillmap is fillmap A, already present in ADD_LIST, A is removed from ADD LIST. This sets ADD LIST to NULL once more: ADDLIST -> NULL 15 As MP.x = 16 < SP.x = 21, control then passes from step 1460 to step 1470, where DP.x = 0 <> MP.x = 16 evaluates to TRUE. Thus, control passes to step 1480, giving: A(O) <-> A(16) <- DP At step 1490, the DP referenced fillmap stack is adjusted by removing fillmap A, giving: 20 A(O) <-> -(16) <- DP Control then passes to step 1492, where the pointer variable MP is advanced past the final merge-map row entry, giving: MP -> NULL Control proceeds through steps 1494 and 1496 and returns via step 1420 to step 1430. 25 Here, the pointer variable DP is assigned as shown: 1236437 v 842229 - 23 A(0) <-> -(16) <-> #(21) <- DP At step 1440 the pointer variable SP is advanced past the end of the strip descriptor: SP -> NULL Control thus flows via steps 1494 and 1496 to return step 1498. On return, the reverse 5 chain of fillmap stacks referenced by pointer variable DP describes strip descriptor 1200. As a further illustration of the method 1330, the process of generating strip descriptor 1230 from merge-map row 1015 and previous strip descriptor 1220 is now considered. Step 1410 from method 1330 initialises variables as follows: MP -> C.o(8) 10 SP -> A(O) DP -> NULL ADDLIST = NULL DELLIST = NULL As MP.x = 8 <= SP.x = 0 evaluates to FALSE, step 1420 is followed by step 1430, 15 where the SP referenced fillmap stack is copied to STACK and assigned to the pointer variable DP, giving: DP -> A(O) At step 1440, the pointer variable SP is then advanced such that: SP -> B/A(7) 20 From step 1440, control then returns to step 1420 via step 1494. Once again, the test at step 1420 evaluates to FALSE, since MP.X = 8 > SP.x = 7. Thus, control flows to step 1430, where the SP referenced fillmap stack is copied to STACK and assigned to pointer variable DP, giving: A(O) <-> B/A(7) <- DP 25 At step 1440, the pointer variable SP is then advanced to the next entry in the source strip descriptor, giving: 1236437 v1 842229 -24 SP -> C/B/A(8) From step 1440, control then returns to step 1420 via step 1494. On this iteration, MP.x = 8 <= SP.x = 8, and so control passes to step 1450, where C is assigned to DELLIST: 5 DELLIST -> C At step 1460, MP.x = 8 < SP.x = 8 evaluates to FALSE, and so control passes to step 1492. Here, pointer variable MP is advanced past the end of merge-map row 1015, giving: MP -> NULL From step 1492, control then returns via steps 1494 and 1496 to step 1420. Because MP 10 is set to NULL, control then proceeds to step 1430. Here, the SP referenced fillmap stack (C/B/A) is copied to STACK. Then, since DELLIST refers to fillmap C, C is removed from the copied stack. This gives a resultant stack (B/A) equivalent to the current DP referenced stack, and so the copied stack is not linked to the pointer variable DP. At step 1440, the pointer variable SP is advanced, giving: 15 SP -> C/B(16) On returning to step 1420, control once again passes to step 1430, where the SP referenced fillmap stack (C/B) is copied to STACK. Removal of fillmap C then gives resultant fillmap stack B, which is linked to the variable pointer DP: A(0) <-> B/A(7) <-> B(16) <- DP 20 From step 1430, control passes once more to step 1440 where the pointer variable SP is advanced: SP -> C(20) The method 1330 then returns to step 1430 via steps 1494 and 1420. Here, the SP referenced fillmap stack (C) is once again copied to STACK. Removal of fillmap C gives 25 a NULL resultant fillmap stack, which is then linked to the variable pointer DP, giving: 1236437 v1 842229 -25 A(O) <-> B/A(7) <-> B(16) <-> -(20) <- DP At this step, fillmap C is removed from DELLIST, since DP.x = 20 >= C.o.x - I = 20. Note here that the value of the variable C.o.x is obtained from the top entry C.o from merge-map row 1010. This gives: 5 DELLIST -> NULL At step 1440, the pointer variable SP is once again advanced, giving: SP -> #(21) A final iteration then sees the SP referenced fillmap stack copied at step 1430, and the pointer variable DP updated to give: 10 A(0) <-> B/A(7) <-> B(16) <-> -(20) <-> #(21) <- DP At step 1440 the pointer variable SP is advanced past the end of the strip descriptor: SP -> NULL Control then proceeds via steps 1494 and 1496 to step 1498. On return from method 1330, the reverse chain of fillmap stacks referenced by pointer variable DP describes strip 15 descriptor 1230. Fig. 15 shows the size of the x-y bounding box for batch display list objects and the x-y size of resultant batch fillmaps. In the diagram, the dotted grid denotes fillmap tile corner points. Thin line 1500 defines the page outline, while thick line 1510 defines the size of the merged fillmap for the page. Batch fillmaps X, Y and Z for the page, with display list 20 bounding boxes 1520, 1530 and 1540 respectively, have encoded fillmap dimensions represented by the thick lines 1550, 1560 and 1570. Note that fillmap Y has cropped horizontal extent, since some portion of the display list for the batch lies outside the leftmost printable section of the page. Similarly, batch fillmap Z has cropped vertical extent, since a portion of the display list for the batch lies below the 25 bottom-most printable section of the page. Fig. 16 is a schematic diagram of a method 1600 carried out by Fillmap Merger 350 of merging a sequence of batch fillmaps from a display list according to an alternative 1236437 v1 842229 - 26 embodiment of the invention. In method 1600 , each successive batch fillmap is merged one at a time with the previous merged result. The method 1600 of Fig. 16 starts at step 1605 and proceeds directly to step 1607, where a fillmap for the current display list batch is generated and stored by 330, as in step 5 810 of method 800. The method 1600 then proceeds to step 1610, where, if the previously generated batch fillmap is the first such fillmap for the page, control then proceeds to step 1640. In this case, the batch fillmap just generated is saved as the resultant fillmap, and the method proceeds to step 1650. If further batch fillmaps remain to be generated, step 1650 returns to step 1607. Otherwise, the method 1600 terminates at step 1660. 10 If the batch fillmap generated at step 810 is not the first such fillmap for the page, control proceeds from step 1610 to step 1620. This step determines: a. the bounding box dimensions of the newly generated fillmap and saved resultant fillmap, in tile units, and b. the top-left position of the new resultant fillmap 15 Step 1620 is followed by step 1622, where a new NULL resultant fillmap is created, as in step 840. Thereafter, the merge-map for the two source fillmaps (the fillmap just generated in step 1607 and the old resultant fillmap saved in step 1640) is generated at step 1624, as in step 850. Following step 1624, step 1626 generates the collection of merge and transfer instructions for the merge-map just produced, as in step 860. 20 From step 1626, the method 1600 proceeds to step 1630, where the two source fillmaps are then merged using the generated collection of merge and transfer instructions, as in step 870. Following step 1630, control passes to step 1640, where the fillmap resulting from step 1630 is saved for subsequent iterations of steps 1620 and 1630. Fig. 17 is a schematic diagram of a method 1700 of merging a sequence of batch 25 fillmaps according to a further alternative embodiment of the invention. This method is similar to the method 1600 depicted in Fig. 16, except that batch fillmaps are only part generated prior to merging. In this progressive merging scheme, tile-high strips of generated batch fillmaps are merged independently of other tile-high strips. The method 1700 of Fig. 17 starts at step 1705 and proceeds directly to step 1707, 30 where a fillmap for the first display list batch is generated and stored as in step 810. Control then proceeds to step 1710, where the fillmap just generated is saved as the current resultant fillmap. From step 1710, the method 1700 proceeds to decision step 1720, where, 1236437 v1 842229 -27 if further batch fillmaps remain to be generated, the method 1700 proceeds to step 1730. Otherwise, the method 1700 terminates at step 1790. At step 1730, a NULL batch fillmap for the current display list batch is created. Then, at step 1740, the size and location of a new resultant (i.e. merged) fillmap is determined 5 from the size and location of the saved resultant fillmap from step 1710 and NULL batch fillmap created at step 1730. From step 1740, the method 1700 proceeds to step 1742 where a new NULL resultant fillmap is created, as in step 840. Steps 1744 and 1746, identical to steps 1624 and 1626, follow directly. With step 1746 completed, control flows to step 1750 where a single tile 10 high strip of the current batch fillmap is generated from the current display list batch. At step 1760, the strip descriptor appropriate to the current tile-high fillmap strip is located. Then, using this strip-descriptor, the method 1700 merges only the just-generated tile-high fillmap strip. From step 1760, control flows to step 1770, where a check is made to see if additional tile-high fillmap strips for the current display list batch must be generated. If 15 additional strips do need to be generated, control then returns to step 1750. Otherwise, control passes to step 1780. At step 1780, all remnant saved fillmap regions need to be transferred to the new resultant fillmap. From the set of strip descriptors generated at step 1746, any transfer instructions referring just to the saved resultant fillmap are executed. This then completes 20 the process of generating the new resultant fillmap, whereupon control passes to step 1710 once again. Fig 18 shows a flowchart of the Merge Fillmaps process 870 (executed on Fillmap Merging Processor 420) according to the preferred embodiment. The process 870 begins at step 1810 where the merge and transfer instructions generated at step 860 are passed in. 25 The fillmap tile transfer processor 430 is then initialised at step 1815. The process of initialisation at step 1815 shall be described below. Step 1820 then iterates through the instructions given to step 1810 by examining whether there are more instructions to execute. If there are more instructions, then step 1830 examines whether the next instruction is a merge or a transfer instruction. If the next instruction is to merge a region, 30 then process 870 proceeds to step 1840 where the region is merged by the fillmap region merger 440. Then the process 870 returns to step 1820. If step 1830 determines that the next region is to be transferred, step 1850 is executed to iterate through all tiles within the 1236437 v1 842229 -28 region. If step 1850 determines that there are more tiles in the region to be transferred, then step 1860 is executed to transfer the next tile using the Tile Transfer Processor 430. Process 870 then returns to step 1850. However, if there are no more tiles to be merged at step 1850, execution returns to step 1820 to process more instructions. If there are no more 5 merge or transfer instructions at step 1820, then process 870 advances to step 1845 where transferred batch fillmaps are accounted for. Step 1845 ensures that batch fillmaps are not deleted prematurely in the subsequent step 1825 where batch fillmaps are cleaned up to avoid storing more batch fillmaps than necessary in the system. The process 870 then ends at step 1890 after step 1825 has been completed. 10 The fillmap region merge processor 440 will now be described with respect to Fig. 19. Batch fillmap regions to be merged are input into the Tile Disaggregator 1910 to be processed a tile at a time by the controller processor 170. Each input batch fillmap tile comprises a set of pixel aligned edges that are entropy encoded. Each tile of the merged fillmap is the combined result of merging the corresponding tile from each batch fillmap. 15 For each merged tile, the corresponding batch fillmap tiles that need to be merged can be pre-processed by a Merge Optimiser 1920 to detect combinations of batch fillmap tiles that can be merged using simpler algorithms. The Merge Optimiser 1920 will be described later with reference to Fig. 24. The Merge Optimiser 1920 is preferably a pass-through module that does not perform any operations. The batch fillmap tiles for a merged tile are then 20 entropy decoded by the Tile decoder module 1930 to prepare the batch fillmap tiles for merging by decoding entropy-encoded edges. An alternative embodiment, where input fillmap tiles comprise pixel-aligned edges that are not entropy-encoded, omits the Tile decoder module 1930. The set of edges that make up each batch fillmap tile is then processed by Scanline processor 1940 to produce spans of fill compositing sequences 25 where each fill compositing sequence is described by the batch fillmap fill compositing sequences that contribute to that span. The fill compositing sequences produced by Scanline Processor 1940 are merged by the Merger and Edge Generator 1950, which also forms edges from the spans and merged fill compositing sequences produced by Scanline processor 1940. Edges that describe the merged fillmap tile are passed to the Tile Encoder 30 module 1960 which entropy encodes the edges. An alternative embodiment that does not entropy encode edges omits the Tile Encoder module 1960. The entropy encoded merged 1236437 v1 842229 - 29 fillmap tiles are collated by Tile aggregator 1970 into a merged fillmap region, which is sent to the Spool Store 360 via bus 175. The high level fillmap merging process 2000 executed by the Fillmap Region Merger module 440 at step 1890 of process 870 will now be described with respect to Fig. 20. Step 5 2010 starts the merging process where batch fillmap regions are input into the Fillmap Region Merge Processor 440. Step 2020 is then executed on the Tile Disaggregator 1910 to determine whether there are more tiles to be merged from the region. If no more tiles need to be merged, then process 2000 exits via step 2040. If there are more tiles to be merged at step 2020, then the next tile from each batch fillmap are merged into a single merged tile in 10 step 2030, which is carried out on the Merge Optimiser 1920, Tile Decoder 1930, Scanline Processor 1940, Merger and Edge Generator 1950, Tile Encoder 1960 and Tile Aggregator 1970 modules. Step 2030 then returns to step 2020. The fillmap tile merge process 2030 will now be described in more detail with respect to Fig. 21. The process 2030 begins at step 2110 where the Tile Disaggregator 1910 receives 15 each batch fillmap tile needed to generate the merged fillmap tile and passes them to step 2120. The number of contributing batch fillmap tiles is determined at step 2120. A batch tile is considered to contribute to the merged tile if all batch fillmap tiles above it in Z order are not fully opaque and the batch tile contains at least one edge whose fill compositing sequence uses a fill that is not the background. A batch fillmap tile is 20 considered to be fully opaque if all of the compositing stacks that describe regions within the tile do not require the background for compositing. Step 2130 determines whether there are more contributing tiles from which to decode edges. If there are, then process 2030 proceeds to step 2140, which decodes the entropy encoded fillmap edges in a tile. The decoding process is carried out by the Tile Decoder module 1930. Step 2140 then returns to 25 step 2130. If no more contributing tiles need to be decoded, then step 2150 is carried out to merge batch fillmap edges from the contributing tiles. Step 2150 is executed by the Scanline Processor 1940 and Merger and Edge Generator 1950 modules. The resultant merged edges from step 2150 are entropy encoded at step 2160 by the Tile Encoder 1960. The encoded merged fillmap tile is then output at step 2170 to be aggregated into the 30 merged fillmap region by the Tile Aggregator 1970. Fig. 22 shows the process of merging edges 2150 in more detail. The process 2150 starts by receiving decoded edges from batch fillmap tiles that contribute to the merged fillmap 1236437 vl 842229 - 30 tile at step 2210. Step 2220 is then executed to iterate through each scanline of the merged tile by checking whether there are more scanlines to be processed. If there are no more scanlines to be processed, process 2150 exits via step 2270. However, when more scanlines need to be processed, then process 2150 proceeds to step 2230 to iterate through each span 5 on the next scanline. A span is the gap described by 2 neighbouring edges crossing at different x-positions along the same scanline. Edges from contributing batch fillmaps tiles are combined to describe spans to be processed at step 2230. Hence, in the merged fillmap tile, a span can be the result of 2 edges from the same batch fillmap or from different batch fillmaps. If there are no more spans to be processed, then execution returns to step 2220. 10 Where there are more spans to be processed, execution proceeds to step 2240 where all batch fillmap edges associated with the current span are determined. A batch fillmap edge is associated with a span if it crosses the current scanline at the same x-position as the starting x-position of the current span. After all batch fillmap edges associated with the current span have been determined, step 2250 is executed to determine all fill compositing 15 sequences for the current span. Step 2250 is carried out by determining the fill compositing sequence referenced by each associated contributing batch fillmap edge. Process 2150 then proceeds to merge the current span into the merged tile in step 2260, which is executed on the Merger and Edge Generator module 1950. Once the span is merged, step 2260 returns to step 2230. 20 Turning to Fig. 23, the process 2260 to merge a span into the merged tile will now be explained. The process 2260 executes on the Merger and Edge Generator module 1950. Process 2260 begins with step 2301 where the span, the fill compositing sequences associated with the span, and all batch fillmap edges associated with the span are passed into the Merger and Edge Generator module 1950. Step 2320 then determines the current 25 span's fill compositing sequence by combining or "stacking" the batch fillmap compositing sequences associated with the span according to their Z-order. Step 2314 then determines whether the current span's fill compositing sequence is equivalent to the fill compositing sequence referenced by the edge associated with the previous span on the current scanline. Each merged fillmap edge refers to a single fill compositing sequence determined by 30 combining batch fillmap compositing sequences associated with spans described by the edge. Two fill compositing sequences are equivalent if they evaluate to the same colour. Alternatively, two fill compositing sequences can be considered equivalent if each of their 1236437 v1 842229 - 31 respective Z-ordered levels has identical attributes. In the preferred embodiment, a fill compositing sequence that only refers to the background is excluded from the comparison since such a fill compositing sequence has no effect on the rendered output. An alternative embodiment may choose to calculate a Cyclic Redundancy Check (CRC) code using the 5 unique identifiers for each batch fillmap fill compositing sequence associated with a span. Each merged edge also stores the CRC code of its constituent spans. In such an embodiment, equivalence can be obtained by comparing the CRC codes of an edge and the current span. Yet another embodiment may implement a table that maps between a CRC code with a fill compositing sequence identifier. In such an embodiment, the equivalence 10 test at step 2314 can be carried out by comparing whether the identifier of the fill compositing sequence mapped to by the span's CRC code matches that of the previous span. If the CRC code does not exist in the table, the batch fillmap fill compositing sequences are merged and a new mapping entry is created in the table. It should be noted that since it is possible for different batch fillmap fill compositing sequence combinations 15 to produce the same merged fill compositing sequence, it is thus possible to map different CRC codes to the same merged fill compositing sequence identifier. If the equivalence test at step 2314 is unsuccessful, then step 2302 determines the candidate edge(s) and top batch fillmap edge for this span. The top batch fillmap edge is the input edge from step 2301 that has the highest z-level. A merged fillmap edge is a 20 candidate edge for a batch fillmap edge if the merged fillmap edge is associated with the span created by the batch fillmap edge on the previous scanline. In case that there is more than one candidate edge from the list of batch fillmap edges from step 2301, the candidate edge belonging to the edge with the highest z-level is preferably chosen. An alternative embodiment may choose to keep a list of candidate edges for further processing. After the 25 candidate edge and top batch fillmap edge have been determined, process 2260 proceeds to step 2303 to examine whether a candidate edge was found. If there is a candidate edge, then step 2303 progresses to step 2304, where it is determined whether the candidate edge remains open and can connect to the current span. An edge can connect to the current span if they have the equivalent merged fill compositing sequence and the current span touches 30 the span defined by the candidate edge on the previous scanline. Two spans from neighbouring scanlines are considered to "touch" if at least a pair of pixel representations, the pair including one pixel representation from each span, are in contact with each other, 1236437 v1 842229 - 32 either adjacently or diagonally. This is to say that the pixel representations within the pair are connected in at least one of the 8-way connectivity known in the art. An edge is considered to be open if it has not been extended to define a span on the current scanline and its span on the previous scanline touches the current span or subsequent spans on the 5 current scanline. If the conditions at step 2304 are satisfied, process 2260 proceeds to step 2306 where the candidate edge is extended to include the current span. The extended edge is then assigned to become the candidate edge of the top batch fillmap edge at step 2310, followed by step 2311 where all other batch fillmap edges associated with this span are modified to no longer have a candidate edge. Step 2312 is then executed to close any open 10 edges that define spans on the previous scanline that can no longer touch subsequent spans on the current scanline. If the conditions at step 2304 are not satisfied or there is no candidate edge from step 2303, step 2305 is executed to determine whether this span can connect to an open edge on the previous scanline. If such an open edge is found, process 2260 progresses to step 2307 15 where the edge found at step 2305 is extended to include the current span. Step 2307 then proceeds to step 2310 described above. If step 2305 did not find an open edge that can connect to the current span, then a new edge will be created at step 2308 that references the merged fill compositing sequence. Step 2309 follows step 2308, in which the new edge created at step 2308 is assigned to the top batch fillmap edge as its candidate edge. Process 20 2260 then advances to step 2311 described above. If the equivalence test in step 2314 is successful, the previous span is extended in step 2315 to include the current span. Process 2260 then proceeds to step 2312. The Merge Optimiser 1920 will now be explained with the aid of Fig. 24. The optimisation process 2400 executed by the Merge Optimiser 1920 begins at step 2401 25 where each batch fillmap tile needed to generate the merged fillmap tile is passed to step 2402. The number of contributing batch fillmap tiles is determined at step 2402. The Merge Optimiser 1920 then proceeds to step 2403 where it is determined whether further action is required. If it is determined that there is no contributing batch fillmap tile, then the Merge Optimiser 1920 exits via step 2411. If there is at least one contributing batch fillmap 30 tile at step 2403, then step 2404 follows. If there is only one contributing batch fillmap tile at step 2404, then that tile is transferred to the merged fillmap region using step 2407, in the same manner as step 1860 of process 870. After step 2407 is executed, the Merge 1236437 v1 842229 - 33 Optimiser 1920 terminates. If step 2404 detects more than one contributing batch fillmap tile, then decision step 2405 is carried out to establish whether each of the contributing batch fillmap tiles contain one edge only. A tile contains one edge only if all pixels within that tile refer to the same fill compositing sequence. As such, such a tile's content is greatly 5 simplified when compared to tiles with more than 1 edge because the edge's location at each scanline in the tile is implicitly on the left-hand boundary of the tile and the length of each span associated with the edge is the width of the tile. If all contributing batch fillmap tiles are one-edge tiles, then step 2410 is executed where the merged fill compositing sequence is calculated by combining each batch fill compositing sequence from each 10 contributing batch fillmap and a one-edge merged tile is produced before the Merge Optimiser 1920 exits at step 2411. Step 2410 is much more efficient than the Fillmap Tile Merge Process 2030 because there is no need to iterate through each scanline and each span in order to merge batch fillmap tiles. If step 2405 determines that not all contributing batch fillmap tiles contain only one edge, then a further decision block 2406 is executed to 15 ascertain whether there is only one contributing batch fillmap tile with more than one edge. If the condition at decision block 2406 is satisfied, then step 2408 follows. In step 2408, a copy of the batch fillmap tile with more than one edge is made for the merged fillmap region. Then the fill compositing sequence of all edges in the copied tile is updated by combining each edge's fill compositing sequence with the sequences of other contributing 20 batch fillmap tiles. Step 2408 is more efficient in merging batch fillmap tiles than the Fillmap Tile Merge Process 2030 for the same reasons that step 2410 is also more efficient. After step 2408, the Merge Optimiser 1920 terminates. If step 2406 determines that there is more than I batch fillmap tile with more than one edge, then the Fillmap Tile Merge process 2030 is executed to merge the batch fillmap tiles. 25 An example of merging 2 batch fillmap tiles as in step 2030 will now be described with respect to Fig. 25. The example shows the first 3 scanlines of two fillmap tiles 2510 and 2520 to be merged as well as the merged fillmap tile 2530. As seen in Fig. 25, every span is associated with an edge. If the edge is on the same scanline as the span, the span commences with the edge (commencing edge). In a multiline edge, the span and the edge 30 can be on different scanlines. For example, the background (lower Z-level) fillmap 2510 contains 2 edges - edges 2511 and 2512 - in its first 3 scanlines. The foreground (higher Z level) fillmap 2520 contains 3 edges - edges 2521, 2522 and 2523 - in its first 3 scanlines. 1236437 v1 842229 -34 Edges 2521 and 2522 are associated with fill compositing sequences that need to be composited with a background representation for rendering. Edge 2523 is fully opaque and does not need a background for compositing and rendering. Starting at scanline 0, the Fillmap Tile Merge process 2030 starts new edge 2531 as a result of the span started by 5 batch fillmap edges 2511 and 2521 and ended by batch fillmap edge 2512. Edge 253 I's fill compositing sequence is the combination of edge 2521 and 2511's respective fill compositing sequences. Edge 2531 then becomes the candidate edge for edge 2521 (which has higher Z-level), while edge 2511 has no candidate edge. Similarly, edge 2532 is created and becomes the candidate edge for edge 2512, and edge 2533 is created and becomes the 10 candidate edge for edge 2522. After scanline 0 is processed, merged fillmap edges 2531, 2532 and 2533 are open and ready to continue on the next scanline. On scanline 1, the span started by batch fillmap edges 2511 and 2521 and ended by edge 2523 has candidate edge 2531, which references the same merged fill compositing sequence as the span, so edge 2531 is extended and remains the candidate edge for batch 15 fillmap edge 2521. A new edge 2534 is created in response to the span started by batch fillmap edge 2523 and ended by edge 2512. Batch fillmap edge 2523 then refers to edge 2534 as its candidate edge. The span started by edge 2512 and ended by edge 2522 refer to the same merged fill compositing sequence as the previous span because edge 2523 refers to a fully opaque compositing sequence. So this span is joined onto the span associated 20 with edge 2534 on scanline 1, and edge 2512 no longer has a candidate edge. Finally, the span started by edge 2522 extends its candidate edge 2533, and edge 2533 continues to be the candidate edge for edge 2522. Edge 2532 is closed because it can no longer touch any spans on scanline 1. On scanline 2, edge 2531 is extended in a similar fashion to scanline 1. The span started 25 by edge 2522 and ended by edge 2512 has edge 2533 as its candidate edge. However, the merged fill compositing sequence for this span does not match that of the candidate edge, nor does it match the fill compositing sequence of the open edge 2534. As a result, new edge 2535 is created and becomes the candidate edge for edge 2522. Since edge 2534 can no longer touch subsequent spans on scanline 2, it is closed. The next span started by edge 30 2512 does not have a candidate edge. However, it can connect to the open edge 2533 from scanline 1. So edge 2533 is extended to include this span and becomes the candidate edge for edge 2512. 1236437 v1 842229 - 35 The proposed method and its application to the example shown in Fig. 25 can also be described as follows. The concept of a "candidate edge" relates to identifying, within a newly merged fillmap, adjacent "touching" spans located on multiple scanlines and having identical fill compositing sequence. Reference information of the starting positions of the 5 spans and the common fill compositing sequence is then stored into a common multiline edge. The method is described with respect to source fillmaps 2510, 2520 and merged fillmap 2530, each of which comprises a corresponding set of adjacent scanlines. Each scanline is divided into a respective set of one or more contiguous source spans. Each span comprises 10 contiguous pixels having an identical fill compositing sequence. Reference information of the starting position and the fill compositing sequence of each span, in both the source and the merged fillmaps, is stored in an associated source edge. The source edge may be located on the same scanline(single line source edge, see 2523) or different scanline (multiline source edge, see 2512, 2521 and 2533) from the referenced span. 15 As explained in the previous text, when merging the source fillmaps, the fill compositing sequence for each merged span is obtained by combining the fill compositing sequences of the respective one or more source spans correspondingly positioned in the respective source scanlines. When considering whether a particular merged span (say the third span on the scanline 1 20 of fillmap 2530) can be associated with an edge that has already been defined for a span from a previous merged scanline, the standard procedure is to compare the fill compositing sequence for the particular span with that of each span of the previous scanline(in this case these are the three spans on scanline 0 of fillmap 2530). However, since in real-life fillmaps the number of spans within a scanline can be substantial, this process may be 25 computationally demanding and can require substantial memory resources. Instead, the proposed method includes identifying, on at least one of the source fillmaps, regions of spans located on adjacent scanlines and having identical fill compositing 1236437 v1 842229 -36 sequence. The starting positions of the spans within one region define a demarcation line (e.g. the line defined by edge 2531). A reference to information of the fill compositing sequence and the starting position of each span within the region can, but does not have to, be included in a multiline source edge (e.g. 2531). One such region includes at least a pair 5 of spans. The proposed method is applicable only to merged spans located on scanlines other than the first scanline of the merged fillmap. For optimising the process of storing information regarding a given merged span, also referred to as a first merged span, the fill composition sequence of the span is compared with that of a second merged span from the preceding 10 adjacent scanline. The second merged span is chosen by looking at the original source fillmap 2520 which defines the fill composition sequence of the first merged span. The second merged span is the merged span, the starting point of the corresponding source span of which lies on the same demarcation line, within the original source fillmap, as the starting point of the source span corresponding to the first merged span. In the case of Fig. 15 25, as the third span on scanline I of fillmap 2530 has been nominated as a "first merged span", the "second merged span" would be the third span of scanline 0 of fillmap 2530. This is so because the source spans in source fillmap 2520, which correspond to the two merged spans, lie on the same demarcation line 2522. If the fill composition sequence of the first merged span matches that of the second 20 merged span, a reference to the starting position and the fill compositing sequence of the first merged span is stored into a multiline merged edge that crosses the starting position of the second merged span. In the case of Fig. 25, "the first merged span" (which is the third span on scanline I of fillmap 2530) has the same fill composition sequence as the "second merged span"( which is the third span on scanline 0 of fillmap 2530). Accordingly without 25 any further calculations, the reference data for the "first merged span" is stored in a multiline edge 2533 which already includes the reference data of the "second merged span". However, if the fill composition sequence of the first merged span does not match that of the second merged span, the fill composition sequence of the first merged span can be 30 compared with that of a third merged span. The third merged span is also from the preceding adjacent scanline and is again chosen by considering the respective source fillmaps. The third merged span is the merged span, the starting point of the corresponding 1236437 v1 842229 - 37 source span of which lies on the same demarcation line as the starting point of the source span of a fourth merged span. The fourth merged span is a span that contiguously precedes the first merged span on the same scanline. An example can be given with the third span on scanline 2 of fillmap 2530. No other ("second") merged span on the predecessing 5 scanline I of fillmap 2530 will form a pair with that span, such that the corresponding starting positions of the corresponding source spans, in either fillmap 2510 or 2520, lie on a demarcation line. However, the second span on scanline 2 of fillmap 2530 (the "fourth merged span") and the third span of scanline 1 of fillmap 2530 (the "third merged span") pair up so that the starting positions of their corresponding spans in fillmap 2520 lie on the 10 demarcation line of multiline edge 2522). If the fill composition sequence of the first merged span(the third span on scanline 2 of fillmap 2530) matches that of the third merged span, information of the first merged span is stored into a multiline merged edge crossing the starting position of the third merged span. Since the fill composition sequence of the third span on scanline 2 of fillmap 2530 indeed 15 matches that of the third span of scanline 1 of fillmap 2530, the reference information of the third span on scanline 2 of fillmap 2530 is stored in multiline edge 2533, associated with the "third merged span". Referring now to Fig. 26, the process 1815 of initialising the fillmap tile transfer processor 430 is described. The fillmap tile transfer processor 430 comprises two sub 20 processors - the data copy processor 432 and the pointer copy processor 434. At decision block 2601 the tile transfer processor 1815 determines if the destination of the transfer is a batch fillmap. If the destination is not a batch fillmap then the fillmap transfer processor 430 is set up to use the data copy processor 432 at step 2620. The process 1815 then concludes. Alternatively, if the destination fillmap is a batch fillmap, then process 1815 25 proceeds to decision block 2602, where it is determined if a predetermined threshold called the CopyThreshold is reached by the current state. In the process 1815 according to the preferred embodiment, CopyThreshold is the total number of batch fillmaps currently in existence in the system. Alternatively, the CopyThreshold may be memory usage. If the CopyThreshold is exceeded, then process 1815 proceeds to step 2620. Alternatively, if the 1236437 v1 842229 -38 threshold is not exceeded at step 2602, then the fillmap transfer processor 430 is set up to use the pointer copy processor 434 at step 2630. The process 1815 then concludes. Hence it can be seen that step 1860 will either use the pointer copy processor 434 or the data copy processor 432 to perform fillmap tile transfers. 5 Referring now to Fig. 27, the process 2700 carried out by data copy processor 432 at step 1860 will be described. The source and the destination tiles are passed into the processor 432. At step 2701, the data is copied from the source to the destination location. At decision block 2702, it is determined whether the source fillmap is already in the Parent Fillmaps List. If it is not in the parent Fillmaps List, the process 2700 proceeds to block 10 2703 where the source fillmap is added to the current fillmap's Parent Fillmaps List. The process 2700 then proceeds to block 2704 where the source fillmap is tagged as having data copied from. Alternatively, if the source fillmap is already in the Parent Fillmaps List, then the process 2700 proceeds to block 2704. After process 2704, the process 2700 concludes. 15 Referring now to Fig. 28, the process 2800 carried out by pointer copy processor 434 at step 1860 will be described. The source and the destination tiles are passed into the processor. At process 2801, the pointer or identifier to the location of the source fillmap tile data is copied from the source fillmap to the destination fillmap. At decision block 2802, it is determined whether the source fillmap is already in the Parent Fillmaps List. If it 20 is not in the parent Fillmaps List, the process 2800 proceeds to block 2803 where the source fillmap is added to the current fillmap's Parent Fillmaps List. The process 2800 then concludes. Alternatively, if the source fillmap is already in the Parent Fillmaps List, then the process 2800 concludes. Referring now to Fig. 29, the process 1845 to account for transferred batch fillmaps will 25 be described. It is necessary to account for batch fillmaps that have been transferred using the pointer copy processor to avoid those batch fillmaps from being prematurely deleted. Process 1845 begins at step 2910 where all batch fillmaps used in the merging process is passed in. Step 2920 then determines whether the fillmap transfer processor 430 is setup to use the pointer copy processor. If it is not, then no batch fillmaps need to be accounted for 30 since all batch fillmap data has been copied to the merged fillmap. However, if the fillmap transfer process 430 is using the pointer copy processor, then step 2930 is executed to iterate through all batch fillmaps that have been merged. If there are no more batch 1236437 v1 842229 - 39 fillmaps, process 1845 exits via step 2960. If there are more batch fillmaps at step 2930, then process 1845 advances to step 2940 where it is determined whether the batch fillmap has been transferred during the merging process. A batch fillmap is considered to have been transferred if any of its tiles have been transferred to the merged fillmap. If the batch 5 fillmap has been transferred, then step 2950 is executed to increment the batch fillmap's Copy Counter by 1. Process 1845 then returns to step 2930. If step 2940 determines that the batch fillmap has not be transferred, then process 1845 also returns to step 2930. The process 1825 of batch fillmap clean up will now be described with respect to figure 30. The clean up process starts with step 3010 where the batch fillmaps that have been 10 merged are passed in. Step 3020 then decides whether there are more batch fillmaps to be processed. If no more batch fillmaps need to be cleaned up, then process 1825 exits via step 3040. Otherwise, process 1825 proceeds to step 3030 where the batch fillmap is cleaned up. Process 1825 then returns to step 3020. Referring now to Fig. 31, the Fillmap Deletion Processor 3030 will be described. The 15 processor receives a fillmap to be deleted. At decision block 3101, the Copy Counter is checked to see if it is zero (0). If the Copy Counter is not equal to zero, the process concludes. Alternatively, if the Copy Counter is equal to zero, then the process proceeds to decision block 3102. At decision block 3102, the processor determines whether the Parent Fillmaps List is empty. If the list is empty then the process proceeds to step 3106 where the 20 fillmap is physically deleted. The process then concludes. Alternatively, if the Parent Fillmaps List is non-empty, the process proceeds to block 3103 and the next fillmap is obtained from the list as the current fillmap to be processed. The process then decrements the Copy Counter of the current Fillmap at step 3104. Then it proceeds to recursively call the Fillmap Deletion Processor 3030 to process through the current fillmap's Parent 25 Fillmap List. After processing through the current fillmap's Parent Fillmap List, the processor proceeds to step 3105 where the current fillmap is removed from the Parent Fillmap List. The processor then proceeds back to decision block 3102 to determine whether the list is now empty. Turning to Figs. 32A to Fig. 32J, an example is shown of transferring contributing tile to 30 output tile when merging, where the number of contributing tiles is one. Each fillmap in the diagram contains the Parent Fillmap List shown by the square brackets [] and, underneath the list, the Copy Counter for that Fillmap. 1236437 v1 842229 - 40 Referring to Fig. 32A, two Fillmaps - Fillmap One 3201 and Fillmap Two2 3202 are present in the display list. Both Parent Fillmap Lists are empty and the Copy Counters are zero. Turning to Fig. 32B, the two fillmaps are merged to Fillmap Three 3203 using pointer copy process 2800. The Copy Counters for both Fillmap One and Fillmap Two have been 5 incremented by 1. The Parent Fillmap List for Fillmap Three has been populated with the contributing Fillmap's IDs. Turning to Fig. 32C, Fillmap Two is copied to create Fillmap Four 3204. The Copy Counter for Fillmap Two 3202 is incremented from one to two and the Fillmap Parent List for Fillmap four is populated with the id 2. Referring to Fig. 32D, Fillmap Three 3203 and Fillmap Four 3204 are merged to create 10 Fillmap Five 3205 using the data copy process 2700. The Copy Counters are not incremented for Fillmap Three and Fillmap Four, while the Fillmap Parent List for Fillmap five is populated. After Fillmap Five is processed, the Deletion process 3030 is called. Now referring to Fig. 32E to Fig. 32J, an example of the deletion process 3030 is shown. 15 Firstly, Parent Fillmap List of Fillmap Five 3205 is processed. The first Fillmap to process is then Fillmap Three 3203. Fillmap Three's Copy Counter is then checked, and as it is equal to zero, it needs to be processed. Processing through its Fillmap Parent List, it is determined that it contains 1 and 2. Turning to Fig 32F, Fillmap One 3201 is now processed. As Fillmap One is processed, its Copy Counter is decremented from one to zero. 20 After this, the Fillmap Deletion Processor 3030 is called. Fillmap One's Copy Counter is compared to 0. As it is equal to 0, its Parent Fillmap List is processed. As it is empty, Fillmap One is physically deleted through process 3106. The ID of Fillmap One is now removed from Fillmap Three's Parent Fillmap List at process 3105. Turning to Fig. 32G, Fillmap Two 3202 is now processed, and the Copy Counter is decremented from two to 25 one at step 3104. Fillmap Two is then similarly processed by the Fillmap Deletion Processor 3030. The ID of Fillmap Two is now removed from Fillmap Three's Parent Fillmap List, which is now empty. Fillmap Three can then be deleted by process 3106. Turning to Fig. 32H, the ID of Fillmap Three is now removed from Fillmap Five's Parent Fillmap List. The next Fillmap in Fillmap Five's Parent Fillmap List is processed by 30 process 3030. Similarly, referring to Fig 321, Fillmap Two is processed by process 3030. Finally, Fillmap Two and then Fillmap Four are physically removed, leaving only Fillmap FIve in memory as shown in Fig. 321. 1236437 vI 842229 -41 The foregoing describes only some embodiments of the present invention, and modifications and/or changes can be made thereto without departing from the scope and spirit of the invention, the embodiments being illustrative and not restrictive. For example, an electronic apparatus, an executable computer program and a computer program product, 5 comprising computer readable medium having a computer program recorded therein, which are configured to perform the proposed method are also within the scope of the invention. 10 INDUSTRIAL APPLICABILITY It is apparent from the above that the arrangements described are applicable to the printing, computer and data processing industries. 1236437 v1 842229