S&F Ref: 888727 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 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(1 895032_1) - 1 EFFICIENT FILLMAP MERGING TECHNICAL FIELD The present disicusre relates to page description language (PDL) rendering, and in particular to rendering PDL files of high complexity. BACKGROUND 5 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 being provided to device driver software of the device in a page description language (PDL), such as Adobe@ PostScript@ 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 10 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-1 1 in the UnixTM operating system. The page is typically rendered for printing and/or display by an object-based graphics system, also known as a Raster Image Processor (RIP). 15 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 host computer to printer connection may be over a 10/10OBaseT Ethernet network that is shared with other users and equipment. In such cases the 20 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 actual time spent transmitting the description of 1894093_1 888727_speci -2 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. 5 In a PDL-based printer the PDL file that describes the page is delivered over the 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 printing. PDL interpretation is a task that requires considerable software and/or hardware resources to perform in a reasonable time. 10 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 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 15 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 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. 20 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 generation using the limited memory and processor resources available in a printer system. Consequently, several methods have been utilized to 1894093_1 888727_speci -3 enable PDL printers to process highly complex input PDL jobs prior to final pixel generation. One method involves dividing a complex PDL input into batches of foreground objects which are scan-converted and composited onto a background bitmap. The 5 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 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, 10 but they suffer the same disadvantages as this method. In another method, a batch of consecutive PDL input objects is converted to a region-based representation 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 15 representation of the region-based batch representation. 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. This merging process can be improved by associating output regions with input regions. A drawback of these methods is their relatively inefficient run-by-run processing. In particular, it fails to take advantage of the 20 inter-scanline coherence of pixel-aligned regions in the region-based representation. In an edge-based rendering system, a list of the edges that intersect a scanline is created, ordered by the x-position of the point where an edge crosses the scanline. On the following scanline edge positions are updated, new edges are inserted, and edges that terminated on the previous scanline are removed from the active edge list. One method 1894093_1 888727_sped -4 uses these active edge lists to render scanlines to pixels. Compositing operations are stored and associated with edges in the active edge list for one scanline. On the next scanline, if the order of edges in the active edge list is unchanged, then these compositing operations can be re-used. If the active edge list has changed, then those 5 compositing operations associated with edges to the right of that point in the scanline need to be recreated. Another method converts vector input objects into a fillmap representation. In this method, the pixel-aligned edge of a fillmap region is associated with an edge in the active edge list for a scanline. On the following scanline, the compositing operations for 10 the fillmap region and its associated edge are compared. If these compositing operations are the same, then the fillmap edge is extended to include the pixel-aligned position of the associated edge. Disadvantages of such previous methods include high computational complexity and high memory storage requirements. Consequently, a need exists for a method for 15 merging batched PDL input objects into a single representation with greater efficiency. SUMMARY Disclosed is a method for merging at least two source fillmaps into a merged fillmap. The method creates an x- then z-ordered list of source edges of the source fillmaps on a first scan line and calculates the merged edges of the merged fillmap from 20 the list of source edges on the first scan line. Each merged edge is associated with a source edge on the first scan line and the list of source edges on a second scan line is updated. The method then uses the x- then z-order in the list of source edges from the first scan line to test, for each source edge on a second scan line, whether the association 1894093_1 888727_speci -5 is valid on the second scan line and extends the merged edge along its associated source edge if the association is valid for said second scan line. BRIEF DESCRIPTION OF THE DRAWINGS Various methods and apparatus will now be described with reference to the 5 following drawings, in which: Fig. 1 shows a schematic block diagram of a pixel rendering system for rendering computer graphic object images; Fig. 2a is an example of a tile; Fig. 2b is an example tiling of an A4 page with printer resolution of 600dpi using 10 blocks of 8 x 8 pixels; Fig. 3 is a flowchart of an exemplary method of processing of a PDL job; Fig. 4 is a flowchart of the process modules within an exemplary fillmap merger; Fig. 5 is an exemplary high level fillmap merging process; Fig. 6 is an exemplary fillmap tile merge process; 15 Fig. 7 is an example of two source edge lists being merged into a single merge edge list; Fig. 8 shows the exemplary process of merging edges in more detail; Fig. 9 is a flowchart showing an exemplary process of updating the source and merge edge lists and identifying the edges that are dirty; 20 Fig. 10 is a flowchart of an exemplary update and delete process in more detail; Fig. 11 is a flowchart of an exemplary edge sorting process; Fig. 12 is a flowchart of an exemplary edge insertion process; Fig. 13 is a flowchart of an exemplary process for resolving merged span; Fig. 14 is an example of the operation of the exemplary edge insertion process. 1894093_1 888727_speci -6 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 5 reference to fillmap representations of pages to be rendered in a pixel rendering system. However, it is not intended that the present disclosure be limited to the described arrangements. For example, the disclosure may have application to any arrangement utilizing pixel aligned edge representations. Fig. I shows a schematic block diagram of a pixel rendering system 100 for 10 rendering 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 20 form of an 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. 1894093_1 888727_speci -7 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 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 5 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 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 10 bitmap image or a tiled (i.e. repeated) image. 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 15 "fillmap" should be understood as referring to a pixel resolution representation of a set of components of a graphical object derived from a page description. However, with regard to an exemplary 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. 20 In contrast to the raster 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 1894093_1 888727_speci -8 contains 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 5 at specified pixel locations. 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. 10 The pixel rendering apparatus 180 then uses the second set of primitives to render the 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 an exemplary arrangement manage fillmap data in tiles. For the purposes of this disclosure a tile shall refer to a block of N by M pixels, 15 where there are multiple blocks across the width of the page and multiple blocks down the 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, although any other number of blocks can be used. For example for an A4 page at a printer resolution of 600 dpi, a suitable choice for tile dimensions is 20 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 tile row occupies pixel location (0, 0), whereas the last pixel 203 in first tile row occupies pixel location 1894093_1 888727_speci -9 (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 5 (X, Y). 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 PDL job via the network 150. The PDL interpreter 310, executed as part of 10 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 15 create a "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 an exemplary 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 20 merged fillmap. 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 1894093_1 888727_speci -10 batch fillmaps in fillmap 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 embodiment will use less memory 190 to store batch 5 fillmaps at the expense of potentially merging graphic objects that will be obscured by another batch fillmap with higher Z-order. It should be appreciated that all elements discussed with respect to Figs. I and 3, can be either software-based or hardware components, embedded or otherwise. The fillmap merger 350 will now be described with respect to Fig. 4. Batch 10 fillmaps to be merged are input into the Tile Disaggregator 410 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. The batch fillmap tiles for a merged tile are then entropy decoded by the Tile decoder module 430 15 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 430. The set of edges that make up each batch fillmap tile is then processed by Scanline processor 440 to produce spans of fill compositing sequences where each fill compositing sequence is described by the 20 batch fillmap fill compositing sequences that contribute to that span. The fill compositing sequences produced by Scanline Processor 440 are merged by the Cached Merger and Edge Generator 450, which also forms edges from the spans and merged fill compositing sequences produced by Scanline processor 440. Edges that describe the merged fillmap tile are passed to the Tile Encoder module 460 which entropy encodes 1894093_1 888727_speci -11 the edges. An alternative embodiment that does not entropy encode edges omits the Tile Encoder module 460. The entropy encoded merged fillmap tiles are collated by Tile aggregator 470 into a merged fillmap region, which is sent to the Spool Store 360 via bus 175. 5 The high level fillmap merging process 500 executed by the Fillmap Merger 350 will now be described with respect to Fig. 5. Step 510 starts the merging process where batch fillmaps are input into the Fillmap Merge 350. Step 520 is then executed on the Tile Disaggregator 410 to determine whether there are more tiles to be merged. If no more tiles need to be merged, then process 500 exits via step 540. If there are more tiles 10 to be merged at step 520, then the next tile from each batch fillmap are merged into a single merged tile in step 530, which is carried out on the Tile Decoder 430, Scanline Processor 440, Merger and Edge Generator 450, Tile Encoder 460 and Tile Aggregator 470 modules. Step 530 then returns to step 520. The fillmap tile merge process 530 will now be described in more detail with 15 respect to Fig. 6. The process 530 begins at step 610 where the Tile Disaggregator 410 receives each batch fillmap tile needed to generate the merged fillmap tile and passes them to step 620. The number of contributing batch fillmap tiles is determined at step 620. 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 20 whose fill compositing sequence uses a fill that is not the background. A batch fillmap tile is 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 630 determines whether there are more contributing tiles from which to decode edges. If there are, then process 530 proceeds to step 640, which decodes the entropy encoded fillmap edges in a 1894093_1 888727_speci - 12 tile. The decoding process is carried out by the Tile Decoder module 430. Step 640 then returns to step 630. If no more contributing tiles need to be decoded, then step 650 is carried out to merge batch fillmap edges from the contributing tiles. Step 650 is executed by the Scanline Processor 440 and Merger and Edge Generator 450 modules. 5 The resultant merged edges from step 650 are entropy encoded at step 660 by the Tile Encoder 460. The encoded merged fillmap tile is then output at step 670 to be aggregated into the merged fillmap region by the Tile Aggregator 470. The structure of the source edge lists and merge edge list will now be described with respect to Figure 7. Fig. 7 is an example of two source edge lists being merged into 10 a single merge edge list. The edge records 710 for edges in a source fillmap that intersect a current scanline are placed into a source edge list in order of their x-position on the scanline (ie. an x-ordered source edge list). Each edge record contains links 720 to the previous and next edges in the source edge list. The merge edge list consists of the edge records from two or more source edge 15 lists ordered by x-position within the current scanline. Each edge record also contains links 730 to the previous and next edge records in the merge edge list. In some cases a stack of edges 740 can occur if there are two or more edges with the same x-position in different source edge lists. In this case, the edge with the higher z-level is placed first in the merge edge list. 20 Fig. 8 shows the process of merging edges 650 in more detail. The process utilizes the x- then z-order in the list of source edges from the first scan line to test, for each source edge on a second scan line, whether an association is valid on the second scan line. The process 650 begins at step 801 and proceeds to step 805 which determines whether there are more scanlines to process. If there are no more scanlines the process 1894093_1 888727_speci - 13 terminates via step 899. If there is a further scanline, the process executes to step 810 which updates the source edge lists and merge edge list for this scanline. During step 810 any edges in the source edge list whose merged compositing stacks are likely to have changed are marked as "dirty". The process then executes step 815 which determines if 5 any edges on the scanline have been marked as dirty. If there are no dirty edges, the method proceeds to step 820 which extends all edges in the output tile along their associated edges in the merge edge list, and then returns to step 805. If step 815 finds that the merge edge list for this scanline does contain dirty edges, the method proceeds to step 825, which determines whether there are further 10 edges in the merge edge list to process. If there are no further edges the method returns to step 805. If there is a further edge to process the method then executes step 830, which evaluates whether this edge is obscured. If the edge is obscured then the method executes step 835 where the span between it and the next edge is added to the previous 15 merged span. The method then returns to step 825. If the edge is not obscured, the method proceeds to step 840 which evaluates whether the edge is clean and has an association with an open edge in the output tile. An edge can connect to a span on the previous scanline if they have the equivalent merged fill compositing sequence and the current span touches the span defined by the candidate 20 edge on the previous scanline. Two spans from neighbouring scanlines are considered to "touch" if at least a pair of pixel representations, with the pair including one pixel representation from each span, are in contact with each other, 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. An edge is considered to be open if it has not 1894093_1 888727_speci -14 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 current scanline. If step 840 finds that the edge is clean and has an association with an open output edge, the method executes step 845 which extends the output tile edge along this edge. 5 Step 850 then ends any output edges in the previous scanline that have no possibility of being extended into the current scanline. The method then returns to step 825. If step 840 determines that the edge is not clean or has no association with an open edge in the output tile the method proceeds to step 855. At step 855 the span of pixels between the current edge and the next edge to the right is evaluated to create an 10 output edge, which may be a new edge or the extension of an output edge in the previous scanline. The method then proceeds to step 860 which creates an association between the output edge and the edge in the merge list. The method then returns to step 825. Fig. 9 is a flowchart showing the process 810 of updating the source and merge edge lists and identifying the edges that are dirty. The method begins at step 901 and 15 first executes step 905 which marks all edges in the merge edge list from the previous scanline as clean. The method then proceeds to the update and delete step 910 which updates the x-positions of edges in the source edge list. Step 910 also removes edges from the previous scanline that do not extend into the current scanline from the merge edge list and marks edges affected by these terminated edges as dirty, and inserts new 20 edges into the source lists. The method then executes the sorting step 920 to sort the merge edge list if edges in the source edge lists have crossed and are now out of order. Step 920 marks any edges that have crossed as dirty. 1894093_1 888727_speci - 15 From step 920, the method proceeds to step 930 which inserts new edges into the merge edge list and marks edges affected by the inserted edges as dirty. The process then ends at step 999. Fig. 10 is a flowchart of an exemplary update and delete process 910 in more 5 detail. The process starts at step 1005 and proceeds immediately to step 1010 which determines if there are any further source edge lists to update. If there are no further source edge list the process terminates via step 1099. If there is a further source edge list the method evaluates the list in step 1015 which determines if there are any more edges to update in that edge list. If there are no more edges to update the method first executes 10 step 1020, which inserts new edges into the source edge list, and then returns to step 1010. If there is another edge to update the method proceeds to step 1025 to determine if that edge terminated on the previous scanline. If the edge did not terminate, then the method proceeds to step 1030 where the x-position of the edge on the current scanline is 15 determined. Following step 1030 the method returns to step 1015. If step 1025 finds that the edge did terminate on the previous scanline, the method proceeds to step 1035, which determines whether the terminated edge was in a stack of edges and visible within that stack. If step 1035 evaluates to true, then the method executes step 1040 to mark the edges within the stack as dirty, then proceeds to 20 step 1045. If step 1035 evaluates to false, then the method proceeds directly to step 1045. Step 1045 removes the terminated edge from the merge edge list and source edge list. After executing step 1045 the method proceeds to step 1050 which locates the next 1894093_1 888727_speci -16 edge in the source edge list and sets this point as the end point of the searching carried out by steps 1055 through 1065. The method then proceeds to step 1055 which evaluates whether the next edge in the merge list is at the end point of the search as determined in step 1050. If this edge is 5 at the end point, the method returns to step 1015. If the edge is not at the end point, the method proceeds to step 1060 which evaluates whether the edge both is opaque and has a higher z-level than the terminated edge. If the test in step 1060 evaluates to true, then the method returns to step 1055. If the test in step 1060 evaluates to false, then the method executes step 1065, which marks the edge dirty, before returning to step 1055. 10 Fig. 11 is a flowchart illustrating the edge sorting process 920. The method begins at step 1105 and proceeds directly to step 1110 which determines if there are any further edges in the merge edge list. If there are no further edges the process terminates via step 1199. If there is a further edge the method proceeds to step 1115 which evaluates whether this edge has an x-position to the left of the previous edge in the 15 merge edge list. If the current edge is to the left of the previous edge, then the method proceeds to step 1120 which evaluates whether the current edge both is opaque and has a higher z-level than the previous edge. If step 1120 evaluates to true then the method proceeds to step 1135. If step 1120 evaluates to false then the method proceeds to step 1125. 20 Step 1125 evaluates whether the previous edge both is opaque and has a higher z level than the current edge. If step 1125 evaluates to true then the method proceeds to step 1135. If step 1125 evaluates to false then the method proceeds to step 1130, which marks the previous edge as dirty. The method then proceeds to step 1135. 1894093_1 888727_speci - 17 At step 1135 the current edge is marked as dirty and the method proceeds to step 1140 which swaps the current and previous edges in the merge list. The method then returns to step 1115 to evaluate the current edge against a new previous edge. If step 1115 determines that the current edge is not to the left of the previous 5 edge, then the method proceeds to step 1145 which evaluates whether the current edge is in the same stack as the previous edge and has a higher z-level. If step 1145 evaluates to true, then steps 1135 through 1140 are executed to mark the current edge dirty and swap the current and previous edges, before the method returns to step 1115. If step 1145 evaluates to false, the method executes step 1150 which determines 10 whether the current edge is in a stack on the current scanline and not in that stack on the previous scanline. If step 1150 evaluates to true then the method proceeds to step 1160 in which the edges in this stack are marked as dirty, and then returns to step 1110. If step 1150 evaluates to false, the method proceeds to step 1155 which determines whether the current edge was in a stack on the previous scanline and not in that stack on the 15 current scanline. If step 1155 evaluates to true then the method proceeds to step 1165 to mark the previous edge as dirty before returning to step 1110. If step 1155 evaluates to false then the method returns to step 1110. Fig. 12 is a flowchart illustrating the edge insertion process 930. The process starts at step 1205 and proceeds immediately to step 1210 which determines if there are 20 any further source edge lists to process. If there are no further source edge lists the process terminates via step 1299. If there is a further source edge list the method evaluates the test in step 1215, which determines if there are any more edges in that list that are yet to be inserted into the merge edge list. If there are no more edges to be inserted, the method returns to step 1210. If there is another edge to be inserted, the 1894093_1 888727_speci - 18 method proceeds to step 1220, which evaluates whether there is an edge to the right of the new edge in the source edge list, and whether this edge to the right of the new edge is in the merged edge list. If there is such an edge, the method executes step 1225 which sets the current edge to be that edge. The method then proceeds to step 1230, which 5 determines whether the previous edge will be located before the new edge in the merge edge list order. If the previous edge is before the insertion point of the new edge, the method proceeds to step 1235, where the new edge is inserted into the merge edge list after the previous edge. Following step 1235 the method returns to step 1215. If step 1230 determines that the previous edge is located after the insertion point 10 of the new edge, the method proceeds to step 1240, which evaluates whether the previous edge both is opaque and has a higher z-level than the new edge. If step 1240 evaluates to false, the method proceeds to step 1245 to mark the previous edge as dirty, and then to step 1250. If step 1240 evaluates to true, the method proceeds directly to step 1250. At step 1250 the current edge is set to the previous edge and the method 15 returns to step 1230 to evaluate the new previous edge. If step 1220 determines that there is not an edge to the right of the new edge in the source edge list that is in the merged edge list, the method proceeds to step 1255, which evaluates whether there is an edge to the left of the new edge in the source edge list, and whether this edge to the left is in the merged edge list. If there is such an edge, 20 the method executes step 1260 which sets the current edge to be that edge and proceeds to step 1270. If there is not such an edge, the method executes step 1265 which sets the next edge to be the first edge in the merge list, and then proceeds to step 1270. Step 1270 then determines whether the next edge is located after the new edge in merge 1894093_1 888727_speci - 19 list order. If the next edge is not after the new edge, the method executes step 1275 to set the current edge to the next edge and then returns to step 1270. If step 1270 determines that the next edge is after the new edge, the method proceeds to step 1280 which inserts the new edge into the merge list before the next 5 edge. The method then proceeds to step 1285 which determines whether the end of the merge edge list has been reached. If the end of the merge edge list has been reached the method returns to step 1215. If the end of the merge list has not been reached, the method proceeds to step 1290. At step 1290, the method evaluates whether the next edge both is opaque and has 10 a higher z-level than the new edge. If step 1290 evaluates to false, the method proceeds to step 1295 to mark the next edge as dirty, and then to step 1297. If step 1290 evaluates to true, the method proceeds directly to step 1297. At step 1297 the current edge is set to the next edge and the method returns to step 1285. Turning to Fig. 13, the process 855 to merge a dirty span into the merged tile will 15 now be explained. The process executes on the Merger and Edge Generator module 450. Process begins with step 1301 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 450. Step 1320 then determines the current span's fill compositing sequence by combining or "stacking" the batch fillmap compositing 20 sequences associated with the span according to their Z-order. Step 1314 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 combining batch fillmap compositing sequences associated with spans 1894093_1 888727_speci - 20 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 respective Z-ordered levels has identical attributes. In the preferred embodiment, a fill compositing sequence that only refers to the background is 5 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 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 10 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 test at step 1314 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 15 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 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. 20 If the equivalence test at step 1314 is unsuccessful, then step 1302 determines the candidate edge(s) and top batch fillmap edge for this span. The top batch fillmap edge is the input edge from step 1301 that has the highest z-level. A merged fillmap edge is a 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 1894093_1 888727_speci -21 more than one candidate edge from the list of batch fillmap edges from step 1301, the candidate edge belonging to the edge with the highest z-level is chosen. An alternative embodiment may choose to keep a list of candidate edges for further processing. After the candidate edge and top batch fillmap edge have been determined, process proceeds to 5 step 1303 to examine whether a candidate edge was found. If there is a candidate edge, then step 1303 progresses to step 1304, 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 the span defined by the candidate edge on the previous scanline. Two 10 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, 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. An edge is considered to be open if it has not been extended to define a span on the 15 current scanline and its span on the previous scanline touches the current span or subsequent spans on the current scanline. If the conditions at step 1304 are satisfied, process proceeds to step 1306 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 1310, followed by step 1311 where all other batch fillmap 20 edges associated with this span are modified to no longer have a candidate edge. Step 1312 is then executed to close any open edges that define spans on the previous scanline that can no longer touch subsequent spans on the current scanline. If the conditions at step 1304 are not satisfied or there is no candidate edge from step 1303, step 1305 is executed to determine whether this span can connect to an open 1894093_1 888727_speci -22 edge on the previous scanline. If such an open edge is found, process progresses to step 1307 where the edge found at step 1305 is extended to include the current span. Step 1307 then proceeds to step 1310 described above. If step 1305 did not find an open edge that can connect to the current span, then a new edge will be created at step 1308 5 that references the merged fill compositing sequence. Step 1309 follows step 1308, in which the new edge created at step 1308 is assigned to the top batch fillmap edge as its candidate edge. Process then advances to step 1311 described above. If the equivalence test in step 1314 is successful, the previous span is extended in step 1315 to include the current span. Process then proceeds to step 1312. 10 An example of the operation of this embodiment will now be described using Fig. 14. In this example a background fillmap 1410 and a foreground fillmap 1420 are being merged to produce the output fillmap 1430. The background (lower z-level) source fillmap contains two edges 1411 and 1412 and the foreground (higher z-level) source fillmap contains three edges 1421, 1422 and 1423. Edges 1421 and 1422 are 15 associated with fill compositing sequences that need to be composited with a background representation for rendering. Edge 1423 is fully opaque and does not need a background representation for compositing and rendering. Starting at scanline 0 the Fillmap Tile Merge process 650 creates the source edge lists and merge edge list in step 810. The background source edge list contains the 20 edges 1411 and 1412, the foreground source edge list contains the edges 1421 and 1422, and the merge edge list contains, in order, the edges 1421, 1411, 1412, and 1422. As all of these edges are new edges they are marked as dirty by step 810. For each of these dirty edges in the merge edge list step 855 evaluates the merged span for that edge to create the output fillmap edges 1431, 1432, and 1433. Following this step 860 creates 1894093_1 888727_speci -23 associations between the edges in the merge list and edges in the output fillmap. Output edge 1431 is associated with merge list edge 1421, output edge 1432 is associated with merge list edge 1412, and output edge 1433 is associated with merge list edge 1422. On scanline 1 step 810 updates the source edge lists and merge edge lists. 5 During the update and delete step 910 the edge 1423 is added to the foreground source edge list between edges 1421 and 1422. At the edge insertion step 930 edge 1423 is added to the merge edge list as a dirty edge between edges 1411 and 1412. The insertion of edge 1423 also makes edge 1412 dirty. The merge list now consists of in order the edges 1421, 1411, 1423, 1412, 10 and 1422. As there are dirty edges in the merge list step 815 determines that not all edges can be extended. At step 840 the stack of edges 1421 and 1411 is determined to be clean, so the output edge 1431 which is associated with edge 1421 is extended along the path of edge 1421. Edge 1423 is dirty, so step 855 evaluates the span created by this edge. Step 855 determines that a new output edge 1434 should be created and this edge 15 is associated with edge 1423. Edge 1412 is also dirty, so step 855 evaluates the span that it creates. This span is determined in step 855 to be obscured. Edge 1422 is clean, so the output edge 1433 associated with it is extended along the path of edge 1422. At this point step 860 determines that the span defined by output edge 1432 is unlinkable and this edge terminates on the previous scanline. 20 On scanline 2, step 810 again updates the source edge lists and merge edge lists. During the update and delete step 910 edge 1423 is found to have terminated on scanline 1, so it is removed from the foreground source edge list and merge edge list and edge 1412 is marked as dirty. During the edge sorting step 920, edges 1412 and 1422 are 1894093_1 888727_speci -24 found to have crossed, so both these edges are marked dirty. The merge edge list contains, in order, the edges 1421, 1411, 1422, and 1412. There are again dirty edges in the merge list so step 815 determines that not all edges can be extended. At step 840 the stack of edges 1421 and 1411 is again 5 determined to be clean, so the output edge 1431 which is associated with edge 1421 is again extended along the path of edge 1421. Edge 1422 is dirty so step 855 evaluates the span it creates. Step 855 determines that this is a new region and creates a new edge 1435 which is then associated with edge 1422. Step 855 also finds that the span defined by edge 1434 is unlinkable and so this edge terminates on the previous scanline. 10 Edge 1412 is also dirty and step 855 determines that it describes the same region as edge 1433 did on scanline 1. During step 855 the output edge 1433 is extended along the path of edge 1412 and step 860 removes edge 1433's association with edge 1422 and replaces it with an association with edge 1412. The foregoing describes only some embodiments of merging fillmaps, and 15 modifications and/or changes can be made thereto without departing from the scope and spirit of the present dislcusre, the embodiments being illustrative and not restrictive. For example, an electronic apparatus, an executable computer program and a computer program product, comprising computer readable medium having a computer program recorded therein, which are configured to perform the proposed method are also within 20 the scope of the present disclosure. 1894093_1 888727_sped