S&F Ref: 872145 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): Thomas Benjamin Sanjay Thomas Address for Service: Spruson & Ferguson St Martins Tower Level 35 31 Market Street Sydney NSW 2000 (CCN 3710000177) Invention Title: Retaining edges of opaque groups across bands The following statement is a full description of this invention, including the best method of performing it known to me/us: 5845c(1384499_1) RETAINING EDGES OF OPAQUE GROUPS ACROSS BANDS FIELD OF INVENTION The present invention relates to graphical object rendering and in particular to rendering one or more objects in a Painters-like style into a band or strip buffer. 5 DESCRIPTION OF BACKGROUND ART When a computer application provides data to a target device for printing and/or display, an intermediate description of the page is often given to device driver software in a page description language (PDL). The intermediate description of the page includes 0 descriptions of the graphic objects to be rendered. This contrasts with some arrangements where raster image data is generated directly by the computer application and transmitted for printing or display on the target device. Equivalently, the computer application may provide a set of descriptions of graphic objects via function calls to a graphics device interface layer (GDI). The driver for an 5 associated target device receives the graphic object descriptions from the GDI layer. For each graphic object, the driver is responsible for generating a description of the graphic object in the page description language that is understood by a rendering system of the target device. The rendering system of the target device typically contains a PDL interpreter that parses the graphic object descriptions and builds a display list (DL) of graphic object data. 20 The display list may be implemented using any of a number of known data structures. The rendering system also contains a raster image processor (RIP) that processes the display list and renders the data to an output page image of pixel values comprising for example Cyan, Magenta, Yellow and blacK (CMYK) channels. Once in such a color model, the target device displays or prints the page. 1378676vl - 1 / 25- 872145_Final A graphic object may be a fill region, which contributes colour to the output image, or a clip region. Hereinafter, the term "graphic object", or simply "object", is taken to mean "fill region". Such a graphic object may be clipped by one or more clip regions. A clip region limits one or more graphic objects that the clip region clips to the boundaries of the clip 5 region. That is, portions of a graphic object outside of the intersecting clip are not rendered. Most RIPs utilize a large volume of memory, known in the art as a frame store or a page buffer, to hold a pixel-based image data representation of the page or screen for subsequent printing and/or display. Typically, the outlines of the graphic objects are calculated, filled with colour values and written into the frame store. For two-dimensional 0 computer graphics, objects that appear in front of other objects are simply written into the frame store after the background objects, thereby replacing the background on a pixel by pixel basis. This is commonly known in the art as "Painter's algorithm" or "object-sequential rendering". Objects are considered in priority order, from the rearmost object to the foremost object, and typically, each object is rasterised in scan line order and pixels are written to the 5 frame store in sequential runs along each scan line. These sequential runs are termed "pixel runs". Memory required for rendering an entire page (e.g. A4) using a high dpi (e.g. 1200 dpi) in colour CMYK is large. An alternative to overcome memory constraints is to store only a portion, or band, of a full bit depth output image in memory at any one time. Conventional 20 "banded renderers" render the display list to the band buffer or "band store" one band at a time, starting at the top and working consecutively down the page. While this requires no modification to a pixel-sequential renderer, to employ a conventional object-sequential renderer, objects which extend across bands need their edges to start at correct locations at the start of each band. Some conventional rendering methods use fast tracking to locate a correct 1378676vl -2/25- 872145_Final X location of each edge of each of the object(s) currently being rendered, which are still active from a previous band. Such a method however is computationally expensive when there are thousands of edges which span across multiple bands. SUMMARY OF THE INVENTION 5 It is an object of the present invention to substantially overcome, or at least ameliorate, one or more disadvantages of existing arrangements. According to one aspect of the present invention there is provided a method of band rendering an image comprising one or more objects, said method comprising the steps of: receiving object data representing the objects; 0 for each band, in a band sequential manner: selecting one or more objects from the received object data for a current band; loading stored dormant edges of the selected objects; generating active edges to insert into an active edge list from the selected objects and the loaded dormant edges; 5 rendering the image using the active edge list; and storing active edges in the active edge list as dormant edges in corresponding objects. According to another aspect of the present disclosure there is provided an apparatus for implementing any one of the aforementioned methods. !0 According to another aspect of the present disclosure there is provided a computer program product including a computer readable medium having recorded thereon a computer program for implementing any one of the methods described above. Other aspects of the invention are also disclosed. BRIEF DESCRIPTION OF THE DRAWINGS 25 One or more embodiments of the invention will now be described with reference to the following drawings, in which: Fig. 1 is a schematic block diagram of a system on which arrangements described herein may be practised; Fig. 2 is a schematic block diagram showing a rendering pipeline within which the 30 described arrangements may be implemented; 1378676vl - 3 / 25- 872145_Final Fig. 3 is a schematic flow diagram showing a method of constructing a group based display list; Fig. 4 is a schematic flow diagram showing a method of processing object clips as used in the method of Fig. 3; 5 Fig. 5 is a schematic flow diagram showing a method of adding current object information to a group as used in the method of Fig. 3; Fig. 6 is a schematic flow diagram showing a method of rendering a display list constructed one band at a time according to the method of Fig. 3; Fig. 7 is a schematic flow diagram showing a method of creating a render task as used 0 in the method of Fig. 6; Fig. 8 is a schematic flow diagram showing a method of moving each edge in an Active Edge List (AEL) to dormant edges in each corresponding group or clip as used in the method of Fig 6; Fig. 9 is a schematic flow diagram showing a method of rendering and loading new 5 edges as used in the method of Fig 6; Fig. 10 is a schematic flow diagram showing a method of rendering each scan line as used in the method of Fig 9; Fig. 11 is a schematic flow diagram showing a method of moving or copying dormant edges of a group or clip into the AEL as used in the method of Fig 7; 20 Fig. 12 shows an exemplary page rendered in accordance with the described methods; and Fig. 13 shows the page of Fig. 12 where each group or clip on the page is shown in terms of respective edges. 1378676v1 -4 /25- 872145_Final DETAILED DESCRIPTION OF EMBODIMENTS OF THE INVENTION Fig. 1 shows schematically a system 1 configured for rendering and presenting computer graphic object images. The system includes a processor 2. The processor 2 is also 5 associated with system random access memory (RAM) 3, which may include a non-volatile hard disk drive or similar device 5 and volatile, semiconductor RAM 4. The system 1 also includes a system read-only memory (ROM) 6 typically founded upon semiconductor ROM 7 and which in many cases may be supplemented by compact disk devices (CD ROM) 8 or DVD devices. The system I may also incorporate an engine 10, such as a print engine. 0 The above-described components of the system 1 are interconnected via a bus system 9 and are operable in a normal operating mode of computer systems well known in the art. Also seen in Fig. 1, a rendering apparatus 20 connects to the bus 9, and is configured for the rendering of pixel-based images derived from graphic object-based descriptions supplied with instructions and data from the processor 2 via the bus 9. The apparatus 20 may 15 utilise the system memory 3 for the rendering of object descriptions although the rendering apparatus 20 may have associated therewith a dedicated rendering store arrangement 30, typically formed of semiconductor RAM. The system 1 may be implemented within a printer. The rendering apparatus 20 may be implemented as a hardware device. Alternatively, the rendering apparatus 20 may be a software module resident on the hard disk drive 5 and 20 being controlled in its execution by the processor 2. A rendering pipeline 200 within which the arrangements described herein may be implemented is shown in Fig. 2. A PDL interpreter module 201 converts graphic objects and clip regions described in some page description language to a form that can be understood by a display list builder module 203. The display list builder module 203 may also receive input 25 in the form of function calls to a GDI interface. 1378676vl -5/25- 872145_Final The display list builder module 203 constructs a display list 205 of graphic objects in a form that is optimised for rendering by a RIP module 207. The RIP module 207 renders the display list to an output pixel-based image 210. The PDL interpreter module 201 and display list builder module 203 are preferably 5 implemented as driver software modules running on a host PC processor that is in communication with system 1, for example, via a network. However, as described herein, the PDL interpreter module 201 and display list builder module 203 are implemented as embedded software modules resident on the hard disk drive 5 and being controlled in their execution by the processor 2 within the (printing) system 1. The RIP module 207 is 0 implemented on the rendering apparatus 20 in system 1, which can be a hardware device or a software module as described above. The software modules 201, 203, 205 and 207 may be implemented as computer program code stored upon a storage medium such as the HDD 5 and being controlled in their execution by the processor 2.In particular, the steps of the methods described below may be effected by software instructions carried out within the 15 system 1. The software instructions may be implemented in the form of the software modules 201, 203, 205 and 207. The software may also be divided into two separate parts, in which a first part and the corresponding modules performs the described methods and a second part and the corresponding code modules manage a user interface between the first part and the user. 20 The software may be stored in a computer readable medium, including the storage devices described above, for example. The software may be loaded into the system I from the computer readable medium, and then executed by the system 1. A computer readable medium having such software or computer program recorded on it is a computer program product. 1378676vl -6/25- 872145_Final The use of the computer program product in the system 1 preferably effects an advantageous apparatus for implementing the described methods. The software is typically stored in the HDD 5 or the memory 3. The software is loaded into the system 1 from a computer readable medium, and then executed by the 5 system 1. Thus for example the software may be stored on an optically readable CD-ROM medium that is read by an optical disk drive. A computer readable medium having such software or computer program recorded on it is a computer program product. The use of the computer program product in the system I preferably effects an advantageous apparatus for implementing the described methods. 0 In some instances, the software code modules 201, 203, 205 and 207 may be supplied to the user encoded on one or more CD-ROM and read via a corresponding drive, or alternatively may be read by the user from networks connected to the system 1. Still further, the software can also be loaded into the system 1 from other computer readable media. Computer readable storage media refers to any storage medium that participates in providing 5 instructions and/or data to the system 1 for execution and/or processing. Examples of such storage media include floppy disks, magnetic tape, CD-ROM, a hard disk drive, a ROM or integrated circuit, USB memory, a magneto-optical disk, or a computer readable card such as a PCMCIA card and the like. The operation of the display list builder module 203 will now be described with 20 reference to Fig. 3. Fig. 3 is a schematic flow diagram illustrating a method 300 of constructing a group based display list, carried out by the display list builder module 203. As described above, the display list builder module 203 may be implemented as software resident on the hard disk drive 5 and being controlled in its execution by the processor 2. 1378676vl -7/25- 872145_Final The method 300 begins at step 310, where an object (i.e., the current object) is received from the PDL interpreter module 201 and may be stored in the memory 3. At the next step 320, the processor 2 tests whether all objects have been processed. If so, method 300 ends at step 399 which means a display list is ready to be rendered by the RIP module 5 207. The display list may be stored in memory 3. A method 600 of rendering the display list will be described in detail below with reference to Fig. 6. Otherwise, if all objects have not been processed at step 320, the method 300 proceeds to step 330 where the current object's clips are processed. A method 400 of processing object clips, as executed at step 330, will be described in detail below with reference to Fig. 4. 0 Step 340 follows, where the processor 2 determines whether a new group is needed for the current object, according to various grouping criteria. The grouping criteria may include, for example, distance between the object and group, the number of edges in the group, the clips affecting the group. If the processor 2 determines that a new group needs to be created, then at the next step 370 the processor 2 creates a new group which becomes the current [5 group. The new group may be stored in memory 3. If a new group is not needed at step 340, or following step 370, the method 300 proceeds to step 360. At the next step 360, the processor 2 adds information about the current object ("object information") to the current group configured within RAM 3. A method 500 of adding the current object to the current group, as executed at step 360, will be described in detail below with reference to Fig. 5. 20 At the following step 380 of the method 300, each new edge added to the current group is associated with the current group by the processor 2 so that the RIP Module 207 can quickly find which group each edge came from. At the next step 390, the processor 2 adds the group to the display list in sorted Z order, if not already in the display list. Method 300 then 1378676vl -8/25- 872145_Final returns to step 310 where the processor 2 awaits the next object from the PDL interpreter module 201. Method 400, as executed at step 330 of method 300, will now be described with reference to Fig. 4. The method 400 may implemented as computer program code resident in 5 the HDD 5 and being controlled in its execution by the processor 2. The computer program code implementing the method 400 may form part of the display list (DL) builder module 203. The method 400 begins at step 405, where a variable TempGroupData, which may be configured within the memory 3, is initialised by setting another variable Clip to an empty list (TempGroupData.Clip) configured within memory 3. D At the next step 410, the processor 2 obtains the next clip for the current object. At step 420, if the processor 2 determines that all clips for the current object have been processed, then the method 400 concludes at step 499. Otherwise, the method 400 proceeds to step 430 where the processor 2 adds data for a current clip to a current clip group configured within memory 3. The clip data added in step 430 is all the data required for 5 rendering the current clip. The clip data represents edges, levels and fill rules of the current clip. At the following step 440, the processor 2 associates each edge of the current clip with the current group so that the RIP module 207 can quickly find which clip each edge came from. Finally, at the next step 450, the processor 2 adds a pointer to the current clip in the current clip group to the list, TempGroupData.Clip. Following step 450, the method 400 20 returns to step 410 to process a next clip for the current object. The method 500 of adding the current object to the current group, as executed at step 360, will now be described in detail below with reference to Fig. 5. The method 500 may be implemented as computer program code resident in the HDD 5 and being controlled in its 1378676vl -9 /25- 872145_Final execution by the processor 2. The computer program code implementing the method 500 may form part of the display list builder module 203. The method 500 begins at step 520, where the object information is added to the current group configured within the memory 3. The object information added to the current 5 group is that which will be required by the RIP module 207. In particular, the object information includes the edges, levels, and fill information describing the object. At the next step 530, the clip list associated with the current group is set to the clip list stored in the list, TempGroupData.Clip, configured within the memory 3. A method 600 of rendering a group-based display list, as created by the DL builder 0 module 203 using the method 300, will now be described with reference to Fig. 6. The method 600 may be implemented as computer program code resident in the HDD 5 and being controlled in its execution by the processor 2. The computer program code implementing the method 600 may form part of the RIP module 207. The display list comprises the list of object groups in Z order, and their corresponding clip groups. The method 600 is executed by 5 RIP module 207 to generate an output pixel-based image 210, band by band down a page in a band store preferably forming part of system memory 3. For each band, in accordance with the method 600, the processor 2 identifies a set of render tasks, each render task comprising of a subset of object groups which are visible in the current band. Rendering each render task involves loading inactive or dormant edges which become active into an X coordinate sorted 20 data structure known as an Active Edge List (AEL) configured with system memory 3. Dormant edges will be described in detail below. Between each pair of edges in the AEL, the processor 2 renders colour depending on fill and level information and clipping status. The AEL is modified each time new edges are loaded in, an edges terminates or after each scan line when edge X position may change 1378676vl - 10/25- 872145_Final require sorting. Once there are no more render tasks to render in the current band, the processor 2 goes to the next band and does the same process till all of the bands have been rendered. The method 600 starts at step 605, where a variable, CurY, representing the current 5 scan line to be rendered is set to zero (0). The variable, CurY, may be configured within the system memory 3. At the next step 610, if the processor 2 determines that all bands have been rendered then the method 600 concludes at step 645. Otherwise, at the next step 615, a render task RT is created containing a subset of object groups in the display list to render. Alternatively, the RT may contain an empty list. A method 700 of creating a render task RT, 0 as executed in step 615, will be described in detail below with reference to Fig. 7. The method 700 describes how a render task is created. At step 620, if the processor 2 determines that RT is empty, then the method 600 proceeds to step 630. Otherwise, the method 600 proceeds to step 640. At step 640 of method 600, where the processor 2 move to the next band to be rendered and resets the last 5 group rendered back to the first group in the display list. At step 630, the processor 2 renders the render task RT into the current band. A method 900 of rendering and loading new edges as executed at step 630, will be described in detail below with reference to Fig. 9. At the next step 635, where the processor 2 moves all the edges in the AEL to 20 respective groups and clips. A method 800 moving each edge in the AEL, as executed at step 635, will be described in detail with reference to Fig. 8. Following step 635, the method 600 returns to step 615 where the next render task is created. Each band may have multiple render tasks but no two render tasks reference the same object group. Each consecutive render task 1378676v -11 /25- 872145_Final within a particular band contains object groups which are higher Z priority than the previous render task. The method 700 may be implemented as computer program code resident in the HDD 5 and being controlled in its execution by the processor 2. The computer program code 5 implementing the method 700 may form part of the RIP module 207. The method 700 starts at step 710, where the next group 'Group' is selected by the processor 2. At step 715, if 'Group' is valid then method 700 proceeds to step 720. Otherwise, the method 700 concludes. At step 720, if the processor 2 determines that the group is visible in the current band, then the method 700 proceeds to step 710 to get the next 0 group. Otherwise, the method 700 proceeds to step 725 where the processor 2 tests if Group can be added to RT. Similar to building the display list where step 340 of method 300 put restrictions when objects can merge with the current group, step 725 may put restrictions when group can be added to a render task. These restrictions may include number of groups, number of edges and same clips. If Group cannot be added to RT, at step 725, then the method 5 700 concludes at step 765. Otherwise, the method 700 proceeds to step 730, Group is added to the current render task RT by the processor 2. At the next step 735, the processor 2 adds the dormant edges from Group to the Active Edge List (AEL). A method 1100 of moving or copying dormant edges of a group or clip into the AEL, as executed at step 735, will be described in detail below with reference to Fig. 11.. At the next step 740, the processor 2 gets 20 a clip, Clip, associated with Group. At step 745, if Clip is not valid, then the method 700 returns to step 710. Otherwise, at the next step 755, if the processor 2 determines that Clip is already processed in this RT, then the method 700 proceeds to step 740. Otherwise, the method 700 proceeds to step 760. At step 760, the dormant edges of the Clip are copied to the AEL by the processor 2 in accordance with the method 1100 of Figure 11. At step 735, the 1378676v1 - 12 / 25- 872145_Final dormant edges are directly moved into AEL, while at step 760 the edges are copied and put into the AEL, so the original Clips edges are still dormant. Step 760 is followed by step 740, where the processor 2 gets the next Clip affecting Group. The method 800 of moving each edge in the AEL, as executed at step 635, will be 5 described in detail with reference to Fig. 8. The method 800 may be implemented as computer program code resident in the HDD 5 and being controlled in its execution by the processor 2. The computer program code implementing the method 800 may form part of the RIP module 207. The method 800 moves all edges in the AEL to their corresponding groups or clips, making them dormant. An edge can have three states as follows: 0 Inactive: When the edge has either never been loaded or completely finished rendering and no longer required in current or future bands. Active: When the edge is in the AEL and contributes to the output of the band in the current render task (RT). Dormant: When the edge is with the group or clip and not in the AEL, but will be [5 loaded back into the AEL in a future render task (RT) either in the current or future band. The method 800 begins at step 810, where the processor 2 gets the next edge, Edge, in the AEL configured within the memory 3. At the next step 815, if the processor 2 determines that Edge is valid, then the method 800 proceeds to step 820. Otherwise, the method 800 concludes at step 845. 20 At step 820, if the processor 2 determines that Edge is part of a clip, then the method 800 proceeds to step 830. Otherwise, if Edge is part of a group, then the method 800 proceeds to step 825 where the processor 2 inserts the edge into a group correspond to Edge. Now Edge is considered dormant. Step 810 follows step 825 and the processor 2 gets the next edge in the AEL configured within memory 3. However, if Edge is a Clip, at step 830, if the processor 2 1378676vl - 13 / 25- 872145_Final determines that the Clip will be part of another RT in the current band, then the method 800 proceeds to step 840. Otherwise, the method 800 proceeds to step 835. At step 840, the processor 2 destroys Edge. As described above, the processor 2 makes a copy of dormant clip edge. 5 At step 835, if the processor 2 determines that Edge is the first edge being inserted into Clip for this render task, then the method 800 proceeds to step 837. Otherwise, the method 800 proceeds to step 839. At step 837, the processor 2 deletes all dormant clip edges from Clip. At step 839, the processor 2 inserts Edge into a Clip corresponding to Edge. Now Edge is considered dormant. Step 810 follows both steps 839 and 840. 0 The method 900 of rendering and loading new edges, as executed at step 630, will be described in detail below with reference to Fig. 9. The method 900 may be implemented as computer program code resident in the HDD 5 and being controlled in its execution by the processor 2. The computer program code implementing the method 900 may form part of the RIP module 207. 5 The method 900 starts at step 910, where if the processor 2 determines that all the scan lines in the current band has been rendered, then the method 900 concludes at step 935. Otherwise, at step 915 the processor 2 loads any new unloaded edges which start at the current scan line represented by the variable, CurY, configured within memory 2. If edges which start before CurY are loaded, these edges need to be fast tracked to find the correct X coordinate 0 value for CurY. The processor 2 calculates a value, Nextloadscanline, which is the next scan line after the scan line represented by CurY in the render task where more edges needs to loaded into the AEL. At the next step 920, the processor 2 calculates a number, NLines, as scan lines as the minimum value between the number of scan lines to the end of the band and the number of scan lines to the next scan line where edges need to be loaded into the AEL. At 1378676vl - 14 / 25- 872145 Final the next step 925, the processor 2 renders Nlines scanlines into a band buffer configured within the memory 3. A method 1000 of rendering each scan line, as executed at step step 925, will be described detail below with reference to Fig. 9. Step 910 follows step 925. The method 1000 of rendering of rendering each scan line, as executed at step 925, 5 will be described in detail below with reference to Fig. 10. The method 1000 may be implemented as computer program code resident in the HDD 5 and being controlled in its execution by the processor 2. The computer program code implementing the method 1000 may form part of the RIP module 207. The method 1000 renders Nlines scan lines into the band buffer which is called in step 0 925 of method 900. The data in the band buffer represents the output pixel-based image 210. The method 1000 begins at step 1005, where a check is made to determine if nlines is less than zero (0). If step 1005 returns true (Yes), then the method 1000 ends in step 1099. Otherwise, if step 1005 returns false (No), the method 1000 continues at step 1010. In step 1010, the Active Edge List (AEL) is rendered by the processor 2 into scan line CurY of the 5 output pixel-based image 210 using any suitable pixel sequential rendering algorithm. Processing continues at step 1015. At steps 1015 through to 1045 of the method 1000 the processor 2 updates all the edges in the AEL so that the edges are ready for rendering on the next scan line. In step 1015, a variable Edge configured within the memory 3 is set to be the head of 20 the AEL. Edge represents the current edge to be processed. These are the edges in groups and clips which make up the object shape. In decision step 1020, the processor 2 determines if Edge is valid (e.g., null). If decision step 1020 returns false (No) indicating Edge is invalid, the method 1000 continues at step 1050 described below. Otherwise, if step 1020 returns true (Yes) indicating Edge is valid, the method 1000 continues at step 1025. In decision step 1025, 1378676vl - 15 / 25- 872145_Final the processor 2 determines if Edge exists in the next scan line (CurY + 1). If step 1025 returns false (No), the method 1000 continues at step 1045. In step 1045, Edge is removed from the AEL. The method 1000 continues at step 1040. Otherwise, if decision step 1025 returns true (Yes) indicating Edge exists in the next scan line, the method 1000 continues at 5 step 1035. In step 1035, Edge's X coordinate value (Edge.X) is updated for the next scan line (CurY + 1), i.e. is for rendering. Edge may need to be reinserted, so that AEL remains sorted by X coordinates. In step 1040, Edge is set to be the next edge in the AEL by the processor 2. Processing then continues at step 1020 where the processor 2 determines if the current Edge is 0 valid. When all the edges in AEL have been updated (by means of steps 1020 to 1045), step 1020 returns false (No), and the method 1000 continues at step 1050. In step 1050, nlines is decremented by one (1) and CurY is incremented by one (1) by the processor 2. The method 1000 then returns to step 1005 to check if more lines can be rendered. 5 The method 1100 of moving or copying dormant edges of a group or clip into the AEL, as executed at step 735, will now be described with reference to Fig. 11. The method 1100 may be implemented as computer program code resident in the HDD 5 and being controlled in its execution by the processor 2. The computer program code implementing the method 1100 may form part of the RIP module 207. 20 The method 1100 moves or copies dormant edges from a group or clip into the Active Edge List (AEL) which is called by steps 735 and 760 of method 700. The method 1100 starts at step 1110, where the processor 2 gets the next dormant edge, DEdge. Then at step 1115, the processor 2 tests if DEdge is valid. If DEdge is not valid, then the method 1100 ends at step 1145. Otherwise, at step 1120, the processor 2 tests whether a copy flag, configured within 1378676vl - 16/25- 872145 Final memory 3, is set. The copy flag is set only for step 760 of method 700 which copies the dormant clip edges. On the other hand, step 735 of method 700 does not set a copy Edge flag when calling method 1100. If step 1120 returns true (Yes), then at step 1135, the processor 2 duplicates the edge 5 information DEdge and stores the edge information as DEdge2 within memory 2. Next at step 1140, the processor 2 adds DEdge2 to the AEL in X coordinate sorted order. Otherwise if step 1120 returns false (No), at step 1125, the processor 2 adds DEdge to AEL in X coordinate sorted order. Step 1130 follows step 1125. At step 1130, the processor 2 removes DEdge from the dormant edge list. Following step 1130 or 1140, the method 1100 returns to step 0 1110. Fig. 12 shows an example page 1210. The rendering of the page 1210 in a band by band (or band sequential) manner, in accordance with the described methods, will now be described . The page 1210, which consists of three (3) opaque objects in Z order, is described below: 5 Object 1220 - An opaque rectangle which extends down the page and clipped by clip in 1250. Object 1230 - An opaque circle which is not clipped by any clip. Object 1240 - An opaque upright triangle which is also clipped by clip-in 1250. The objects 1220, 1230 and 1240 on the page 1210 go through the PDL interpreter module 20 201 of Fig. 2 and passed into the DL builder module 203 which creates a Z ordered group based display list 205. For simplicity, in the example of Fig. 12, each group in the display list is assumed to consist of only one (1) object. Thus, the display list contains three (3) groups in the following order: Group 1220 which contains only object 1220 clipped by group clip 1250, 1378676vl - 17/25- 872145_Final group 1230 which contains only object 1230 and group 1240 which contains only object 1240 clipped by group clip 1250. Fig. 13 shows the same page 1210 of Fig. 12, where each group and clip on the page 1210 has been shown in terms of their respective edges. Group 1220 consists of edges 1321 and 5 1322, group 1230 of edges 1331 and 1332, group 1240 of edges 1341 and 1342 and group clip 1250 of edges 1351 and 1352 respectively. Due to memory limitations, the output image 210 contains only enough space for a strip or band buffer. In the present example, page 1210 needs to be rendered in eleven (11) bands BO to B 10. The RIP module 207 renders the display list 205 using the methods 600, 700, 800, 900, 1000 and 1100, described in Figs. 6 to 11. .0 When rendering band BO, no groups are found to exist on this band. So depending on the configuration of the system I either nothing or white is rendered into Band BO. Next bands BI and B2 needs to be rendered, and because of Group Clip 1250 neither Groups 1220 and 1240 are visible in these bands, so nothing or white is rendered into bands B1 and B2. In the present example, it is assumed that a render task must only contain groups sharing 15 the same clips. So for band B3, there is only one (1) render task containing groups 1220 and 1240 as at step 615. Edges 1321, 1322, 1351, 1352, 1341 and 1342 are loaded into the Active Edge List (AEL). Edges 1321, 1322, 1341 and 1342 need to be fast tracked so that all edges in the AEL are at scanline CurY which is the first scanline in band B3. Also, there are no dormant edges in either groups 1220 and 1240 when rendering band B3. Band B3 is rendered 20 with colour data coming out between edges 1351 and 1322 and edges 1341 and 1352 respectively. After rendering the last scanline of band B3, active edges in AEL are put in their respective groups and clips and marked as dormant. So edge 1321 goes to group 1220 dormant list, edge 1351 to clip 1250, edge 1322 to group 1220, edge 1341 to group 1240, edge 1352 to clip 1250 and edge 1342 to group 1240. The AEL is now empty. 1378676v1 - 18/25- 872145_Final When rendering band B4, the same groups 1220 and 1240 are visible. Again only a single render task is required for rendering band B4. No new edges are loaded into the AEL. However, both groups have dormant edges. So dormant edges 1321 and 1322 of group 1220 are loaded and sorted into AEL. Group 1220 is clipped by group clip 1250 which also has 5 dormant edges. Dormant edges are duplicated and edges 1351 and 1352 are loaded and sorted into AEL. Next group 1240 dormant edges 1341 and 1342 are loaded and sorted into AEL. Group 1240 is also clipped by group clip 1250. However, the edges for the group clip have already been added into AEL for this render task, so the dormant edges are not added again. Band B4 is rendered with colour data coming out between edges 1351 and 1322 and edges 0 1341 and 1352 respectively. After rendering the last scanline of band B4, active edges in AEL are put in their respective groups and clips and marked as dormant. The dormant edges already in clip group 1250 is cleaned out in step 837 of method 800 prior to adding the AEL clip edges into group clip 1250's dormant edge list. So edge 1321 goes to group 1220 dormant list, edge 1351 to clip 1250, edge 1322 to group 1220, edge 1341 to group 1240, edge 1352 to 5 clip 1250 and edge 1342 to group 1240. The AEL is now empty. When rendering band B5, groups 1220, 1230 and 1240 are all visible. This will require three (3) render tasks: RI containing group 1220, R2 containing group 1230 and R3 group 1240. The reason three (3) render tasks are required is because group 1230 does not share the same clip 1250 as groups 1220 and 1240, so all the groups cannot be in the same render task. 20 When rendering render task RI, edges 1321 and 1322 will be moved from group 1220's dormant edge list into the AEL. Edges 1351 and 1352 from group clip 1250's dormant edge list will be duplicated and sorted into the AEL as group 1220 is clipped by group clip 1250. After rendering render task R1, there will be colour between the edges 1351 and 1322 and edges in AEL will be put back into their respective groups as dormant edges. So edge 1321 1378676v1 -19 /25- 872145_Final goes to group 1220, edge 1351 is destroyed, 1322 goes to group 1220 and edge 1352 is also destroyed. Note that even though edges 1351 and 1352 were destroyed, there are duplicate dormant edges in group clip 1320. AEL is empty now. Next render task R2, loads edges 1331 and 1332 for the first time into the AEL. After rendering render task R2, colour is rendered 5 between edges 1331 and 1332. Edge 1331 and 1332 are both marked as dormant and put in group 1230's dormant edge list. Next render task R3, edges 1341 and 1342 are moved from group 1240's dormant edge list and edges 1351 and 1352 are copied from group clips 1250's dormant edges into the AEL. Colour is produced between the edges 1341 and 1352. Edges 1341 and 1342 are moved back into group 1240's dormant edge list. Edges 1351 and 1352 0 would have already been deleted from the AEL in step 1045 of method 1000. Rendering in bands B6, B7, B8 and B9 are similar. Only a single render task containing group 1230 is required as no other group is visible. Edges 1331 and 1332 are loaded from dormant edge list of group 1230. No new edges are loaded into the AEL besides the dormant edges. Colour is rendered between the edges 1331 and 1332. After rendering the last scanline .5 in each band, edges 1331 and 1332 are moved from the AEL to the group 1230's dormant edge list. When rendering the final band B10, only a single render task containing group 1230 is required. Edges 1331 and 1332 are loaded from dormant edge list of group 1230. No new edges are loaded into the AEL besides the dormant edges. Colour is rendered between the 20 edges 1331 and 1332. Both edges finish on a scanline X coordinate before the end of the band, so both edges are removed from the AEL in step 1045 of method 1000 at scanline X. In this way page 1210 of Figure 12 is rendered completely in 11 bands with minimal computational overhead of switching between various objects when rendering. Industrial Applicability 1378676vl -20/25- 872145_Final The arrangements described are applicable to the computer and data processing. 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. 5 In the context of this specification, the word "comprising" means "including principally but not necessarily solely" or "having" or "including", and not "consisting only of". Variations of the word "comprising", such as "comprise" and "comprises" have correspondingly varied meanings. 0 1378676vl - 21 / 25- 872145_Final