AU2004237908A1 - Apparatus for printing overlapping objects - Google Patents

Description

S&F Ref: 688277

AUSTRALIA

PATENTS ACT 1990 COMPLETE SPECIFICATION FOR A STANDARD PATENT Name and Address of Applicant: Actual Inventor(s): Address for Service: Invention Title: Canon Kabushiki Kaisha, of 30-2, Shimomaruko 3-chome, Ohta-ku, Tokyo, 146, Japan Vincent Groarke Timothy Jan Schmidt Spruson Ferguson St Martins Tower Level 31 Market Street Sydney NSW 2000 (CCN 3710000177) Apparatus for printing overlapping objects The following statement is a full description of this invention, including the best method of performing it known to me/us:- 5845c -1- O APPARATUS FOR PRINTING OVERLAPPING OBJECTS OField of the Invention The present invention relates generally to computer-based printer systems and, in particular, to inexpensive printer systems for high-speed printing.

00 Background 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® 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 the 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).

A typical printer system comprises a host computer, such as a personal computer 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/100BaseT 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 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 688277 O particular PDL is therefore a crucial factor in minimising the time taken to transfer the O page description from the host computer to the printer.

SIn 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 00 5 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 (Ni N resources to perform in a reasonable time.

SThe advantage of such a system including a PDL-based printer is that the amount of data, that is the description in the PDL, which 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 page to its final arrival out of 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.

In contrast to the system including a PDL-based printer, a system using a hostbased 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, 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. Sometimes halftoning is also performed on this pixel data on the host computer to reduce the size of the pixel data. This approach is also known as the bitmap approach.

688277 -3- A significant advantage of this bitmap approach is that the printer need not be capable of PDL interpretation. 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 translates into cost, 00 5 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.

(Ni The disadvantage of such host-based printing systems is the amount of data that needs to be delivered from host computer to the printer across the interface. An A4 page at 600dpi resolution may require over one hundred megabytes of pixel data to be transferred across this interface when uncompressed. Compressing the pixel data alleviates the problem to some extent, particularly when the pixel data has already been halftoned. However, the data transfer still typically requires many megabytes of compressed pixel data. Apart from the time and memory resource required to process this data in the printer, considerable time is also consumed in simply waiting for these compressed pixels to make their way across the interface from the host computer to the printer. Consequently the host-based printer system is particularly sensitive to increases in page resolution and reduced interface data bandwidth.

A need therefore exists for a representation of a page to be rendered on a printer system that removes the requirement of the printer system to be capable of PDL interpretation without the representation consisting of a large amount of data.

Summary It is an object of the present invention to substantially overcome, or at least ameliorate, one or more disadvantages of existing arrangements.

According to a first aspect of the present disclosure, there is provided a representation of a page to be rendered, said page comprising one or more graphic 688277 -4objects, each graphic object being defined by two or more edges, said representation comprising for each edge on said page: position data of one or more segments forming said edge; for each segment, at least one attribute defining pixel properties of pixels on a scanline in the rendering direction following said segment; and data representing the scanlines over which said at least one attribute is valid.

According to a second aspect of the present disclosure, there is provided a method of rendering a page, said page comprising one or more graphic objects, each graphic object being defined by two or more edges, said method comprising the steps of: receiving a representation of said page, said representation comprising for each edge on said page: position data of one or more segments forming said edge; for each segment, at least one attribute defining pixel properties of pixels on a scanline in the rendering direction following said segment; and data representing the scanlines over which said at least one attribute is valid; determining from said position data the pixel locations at which said segments of said edges cross a current scanline; associating at least one attribute with each span of pixels, each span of pixels being defined by segments crossing said current scanline; and rendering said spans of pixels on said current scanline.

According to another aspect of the present disclosure, there is provided an apparatus for implementing the aforementioned method.

According to another aspect of the present invention there is provided a computer program for implementing the method described above.

688277 Other aspects of the invention are also disclosed.

SBrief Description of the Drawings Some aspects of the prior art and one or more embodiments of the present invention will now be described with reference to the drawings, in which: 00 Figs. 1, 2 and 3 show schematic block diagrams of prior art pixel rendering Cc systems for rendering computer graphic object images; Fig. 4 shows a schematic block diagram of the functional blocks of a pixel rendering apparatus forming part of the prior art pixel rendering system of Fig. 1; Fig. 5 illustrates schematically two overlapping objects for the purposes of illustrating how the prior art pixel rendering systems shown in Figs. 1 to 3 render a page; Fig. 6 shows a schematic block diagram of a pixel rendering system for rendering computer graphic object images according to the present invention; Fig. 7 illustrates the functional blocks of a controlling program in the pixel rendering system shown in Fig. 6; Fig. 8 illustrates schematically a page containing one object for the purposes of illustrating how the pixel rendering system shown in Fig. 6 renders such a page; Fig. 9 illustrates schematically a page containing two completely overlapping opaque objects for the purposes of illustrating how the pixel rendering system shown in Fig. 6 renders such a page; Fig. 10, 11 and 12 illustrate schematically pages containing two overlapping objects for the purposes of illustrating how the pixel rendering system shown in Fig. 6 renders such pages; Fig. 13 illustrates the functional blocks of a pixel rendering apparatus in the pixel rendering system shown in Fig. 6; 688277 -6- Fig. 14 shows a schematic flow diagram of a method 1400, performed by the pixel rendering apparatus 680, of rendering a page; Fig. 15a shows a schematic flow diagram of a method of generating a second set of primitives from a first set of primitives; and 00 Figs. 15b, 15c and 15d show schematic flow diagrams of steps of the method shown in Fig. 15a in more detail.

,I

Detailed Description Where reference is made in any one or more of the accompanying drawings to steps and/or features, which have the same reference numerals, those steps and/or features have for the purposes of this description the same function(s) or operation(s), unless the contrary intention appears.

Aspects of prior art pixel rendering systems are described before describing embodiments of the invention. It is noted however that the discussions contained in the "Background" section and the prior art system described below relate to systems which form prior art through their respective publication and/or use. However, such should not be interpreted as a representation by the present inventor(s) or patent applicant that such documents or systems in any way form part of the common general knowledge in the art.

Fig. 1 shows a schematic block diagram of a prior art pixel rendering system 100 for rendering computer graphic object images. 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.

The personal computer 110 comprises a host processor 120 for executing a software application 130, such as a word processor or graphical software application, and 688277 a controlling program 140, such as a driver on a WindowsTM or MacintoshTM operating O system.

The printer system 160 comprises a controller processor 170, memory 190, a pixel rendering apparatus 180, and a printer engine 195 coupled via a bus 175. The pixel 00 5 rendering apparatus 180 is typically in the form of an ASIC card 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 NI 170.

In the prior art pixel rendering system 100 each graphical object that is passed by the controlling program 140 to the pixel rendering apparatus 180 across the network 150 for processing is defined in terms of the following parameters: edges which describe the geometric shape of the graphical object; a fill which describes the colour, the opacity, the colour blend and/or the image to be painted within the shape of the object; and a level which describes whether an object should be painted above or behind other objects, and how colour and opacity from an object should be combined with colour and opacity from other overlapping objects.

Describing each of the parameters of the graphical object in more detail, and starting with the edges, the edges are used to describe the boundaries of an object. Each edge is provided as a sequence of segments in a monotonically increasing Y sequence.

Edge segments may be straight lines or may be any other type of curve, such as a Bezier curve. Edges may also be used to describe text objects by treating each glyph as a geometric shape whose boundaries are described by edges made up of straight-line segments. Edges are attributed a "direction" by the controlling program 140. This 688277 -8direction is a convention that the pixel rendering apparatus 180 uses to determine how an edge affects the activity of an object's level.

The fill is a description of the colour, pattern or image to be painted within the boundaries of the graphical object. The fill may be a flat fill representing a single colour, 00 5 a blend representing a linearly varying colour, a bitmap image or a tiled repeated) image. In each case the supplied fill is to be applied over the extent of the object. The N controlling program 140 generates fill information for each object on a page that is used by the pixel rendering apparatus 180 during the rendering process.

Each object to be rendered is also assigned a level entry. An object's level entry indicates the relative viewing position of that object with respect to all other objects on a page.

In addition, each level entry created by the controlling program 140 also has a fill rule associated therewith, which may be "non-zero winding", or "odd-even fill". Each level has a fill-count, which is set to zero at the start of each scanline, during the rendering process. As the pixel rendering apparatus 180 processes a scanline working across the page, when a downwards heading edge is crossed, the fill-count of the level or levels associated with the edge is incremented. When an upwards heading edge is crossed, the fill-count of the level or levels associated with the edge is decremented. If a level has a non-zero winding fill rule, then the level is active if its associated fill-count is non-zero. If a level has an odd-even fill rule, then the level is active if its associated fill count is odd.

Yet further, the level entry defines the arithmetic or logical operation which specifies how the colour/opacity from this level is combined with the colour/opacity from other overlapping levels.

688277 -9- F In the pixel rendering system 100, the software application 130 creates pageo based documents where each page contains objects such as text, lines, fill regions, and Simage data. The software application 130 sends a page for printing, in the form of an application job, via a graphics application layer to the controlling program 140. In 00 5 particular, the software application 130 calls sub-routines in a graphics application layer, such as GDI in WindowsTM, or X- 11 in UnixTM, which provide descriptions of the objects (Ni N to be rendered onto the page, as opposed to a raster image to be printed.

SThe controlling program 140 receives the graphical objects from the application program 130, and constructs an instruction job containing a set of instructions, together with data representing graphical objects. In the present context a job represents one page of output. The job is then transferred to the controller processor 170, which controls the pixel rendering apparatus 180, for printing. In particular, a program executing on the controller processor 170 is responsible for receiving jobs from the controlling program 140, providing memory 190 for the pixel rendering apparatus 180, initialising the pixel rendering apparatus 180, supplying the pixel rendering apparatus 180 with the start location in memory 190 of the job, and instructing the pixel rendering apparatus 180 to start rendering the job.

The pixel rendering apparatus 180 then interprets the instructions and data in the job, and renders the page without further interaction from the controlling program 140.

The output of the pixel rendering apparatus 180 is colour pixel data, which can be used by the output stage of the printer engine 195. The pixel rendering apparatus 180 employs a pixel-based sequential rendering method.

The pixel rendering apparatus 180 of Fig. 1 is shown in more detail in Fig. 4.

The pixel rendering apparatus 180 comprises an instruction execution module 410; an edge tracking module 420; a priority determination module 430; a pixel generation 688277 O module 440; a pixel compositing module 450; and a pixel output module 460 arranged in 0 a pipeline. For each scanline the pixel rendering apparatus 180 processes each pixel in Sturn, considering the graphical objects that affect that pixel, to determine the final output for the pixel.

00o 5 The instruction execution module 410 of the pixel rendering apparatus 180 reads and processes instructions from the instruction job that describes the pages to be printed (Ni and formats the instructions into information that is transferred to the other modules 420 Sto 460 within the pipeline.

One instruction is used to command the pixel rendering apparatus 180 to prepare to print a page of a particular dimension. Another instruction indicates that an edge or edges with particular characteristics start at a particular scanline at a particular x-position.

Yet another instruction specifies that the pixel rendering apparatus 180 should load a particular level into the appropriate internal memory region used to hold level information. Yet another instruction specifies that the pixel rendering apparatus 180 should load a particular fill into the appropriate internal memory region used to hold fill information within the printer system 160. Yet another instruction specifies that a particular data set a compressed bitmap for example) should be decompressed using a specified decompression algorithm. The data set to be decompressed must be available in the memory 190 of the printer system 160 before such an instruction is executed by the pixel rendering apparatus 180. Other instructions relevant to the rendering of a page are also decoded by the pixel rendering apparatus's instruction execution module 410.

When executing the instruction job the instruction execution module 410 processes the instructions sequentially. On encountering an instruction to load an edge or edges at a specific scanline the instruction execution module 410 extracts relevant 688277 -11- O information regarding the edge and passes this information onto the edge tracking module 0 420.

SThe edge tracking module 420 is responsible for determining the edges of those graphical objects of the instruction job that intersect the currently scanned pixel and 00 5 passes this information onto the priority determination module 430. When creating the instruction job the controlling program 140 inserts instructions to start an edge or edges in (Ni the appropriate order and at the appropriate scanline such that the pixel rendering Sapparatus 180 maintains a correct list of active edges at every scanline of the page when rendering.

When the edge tracking module 420 receives edge information from the instruction execution module 410, the edge tracking module 420 updates an active edge list 470. The active edge list 470 contains a sorted list of the active edges on the current scanline being rendered by the pixel rendering apparatus 180. The active edge list 470 is updated by inserting the incoming edges into the active edge list 470 and sorting this list by each edge's current x-position.

Once a scanline has been rendered, each edge has its x-position updated by executing each edge's x-position update function. This function returns the edge's xposition for the next scanline render. In the case that an edge terminates before the next scanline, that edge is removed from the active edge list 470. When edges cross the active edge list 470 is resorted.

For each edge that is stored in the active edge list 470 a level or levels will be added or removed from an active level list 490 that is maintained by the priority determination module 430. As the active edge list 470 is traversed level or levels are added to or removed from the active level list 490. The span of pixels between a pair of 688277 -12- O edges has therefore an active level list 490 that is used to control the compositing of the Spixel contributions from each level in the active level list 490.

SThe priority determination module 430 is pre-loaded with a level table 445 from the instruction job. The level table 445 contains an entry for each graphical object 00 5 consisting of its z-order position on the page, how the colour of the object should be combined with other objects (compositing operators), and other data. The priority (Ni N determination module 430 is responsible for determining those objects, so called active objects, that make a visual contribution to the currently scanned pixel and passes that information onto the pixel generation module 440.

The information passed from the pixel determination module 430 to the pixel generation module 440 includes an index that references the fill of a corresponding active object in a fill table 455. The pixel generation module 440 is pre-loaded with the fill table 455 from the instruction job. The fill table 455 contains an entry for each graphical object consisting of the graphical object's fill and other data. The pixel generation module 440, upon receiving information from the priority determination module 430, is responsible for referencing the index into the fill table 455, and using the data therein to generate colour and opacity information which is passed onto the pixel compositing module 450.

The pixel compositing module 450 is responsible for obtaining the final colour for the currently scanned pixel by compositing the fill colours in accordance with the compositing operators as indicated in the rendering instructions. For each level in the active level list 490 for a particular pixel span, the pixels corresponding to the level's object are determined by reference to the fill that is linked to that level. In the case of a simple flat fill, this reference is a trivial lookup of the colour of that object. However, for a bitmap fill a 2-D affine transformation is applied to the y) location of each pixel in the span to determine the source data to be used to colour the pixel on the page, including 688277 -13- O some interpolation method if required. Similarly a non-trivial calculation is required for Sany other fill type that relates a pixel's location on the page to the fill data stored within the printer system's fill table 455, such as a linear gradient.

In order to determine the final colour of pixels within a span, the contributions of 00 5 each level are composited together. Compositing is performed using the transparency of the contributing levels, the colours of the contributing levels and the raster operation (Ni Ci specified for each level in the active level list 490. For a span where the fills of all the N contributing levels for this span each reference a single colour, the compositing algorithm need only compute the resultant colour from compositing one pixel and then repeat this pixel for the whole span.

For a span where the fills of all the contributing levels for this span are of type bitmap or gradient for example, the compositing algorithm needs to compute the resultant colour from compositing all the pixels in the span in turn.

The final output colour of the pixel is passed onto the pixel output module 460, which is subsequently passed to the printer engine 195.

The pixel rendering apparatus 180 described above considers each output pixel fully, applying all required compositing operations before moving onto the next pixel in the raster output. This method is efficient in an ASIC implementation, but is not the most optimal implementation in software. A variation on this pixel rendering apparatus 180 is possible which offers advantages when implemented in software. In this variation, the pixel rendering apparatus 180 applies one of the required compositing operations to all contributing pixels within a span (between two successive edges), before applying the next compositing operation. Once all required compositing operations have been so applied, the resulting pixel span has been fully processed and may be passed to the pixel output module 460. The next pixel span is then considered.

688277 -14- O The distribution of the computational burden of rendering in the pixel rendering Ssystem 100 shown in Fig. 1 between the personal computer 110 and the printer system 160 sees the compositing of pixels being performed on the printer system 160 by the pixel rendering apparatus 180. Compositing in a span where there are N active levels is an 00 5 order-N algorithm. Computing the contribution of each level in the active level list 490 for a page with many overlapping objects can be very time consuming using the process (Ni described above, since the contribution of each level must be calculated for each pixel Sspan. If the fills linked to the active levels within a span are of type flat colour then only a single pixel within the span needs to be individually calculated using the compositing algorithm. All other pixels within the span will be identical. However, if the fills linked to the active levels within a span are of type bitmap, or another non-flat fill, then each pixel within the span needs to be individually calculated using the compositing algorithm.

In order to render in real time for a laser beam printer running at a rated page per minute speed, the processing load on the printer due to compositing must be quantified and catered for in specifying the resource requirements of the printer system 160. In particular, the processing power and memory resources of the printer system 160 must be such that at no time does the pixel rendering apparatus 180 fail to keep up with the consumption of pixels by the printer engine 195 when the laser printer is actually printing the page.

In addition to the compositing of pixels on the page, another task that is performed typically in the printer system 160 is that of Colour Space Conversion (CSC).

Compositing typically takes place in the RGB (Red Green Blue) colour space and hence a CSC is required following the step of compositing before pixels can be shipped to the printer engine 195 for printing onto the page. CSC between the RGB colour space typically used when compositing and the CMYK colour space required by the printer is a 688277 O non-linear operation where typically each of the Cyan, Magenta, Yellow and Black Scomponents are functions of all three RGB components. CSC places a certain processing Sburden on the printer system 160 in order to be executed in a timely manner for real time printing on a laser beam printer.

00 5 Yet another task that is performed typically in the printer system 160 is that of halftoning. Halftoning is applied to pixels that are at page resolution as a method of (Ni reducing the size of data to be transferred to the printer engine 195. In a typical Shalftoning implementation tables are used to reduce each colour channel from an 8-bit (,i value to a 4-bit, 2-bit or 1-bit value.

The operation of the pixel rendering system 100 in processing an instruction job is now described with reference to Fig. 5 wherein two graphical objects 510 and 520 on a page 500 are illustrated. The graphical objects are a triangle 510 with a light grey flat fill, and a square 520 with a dark grey flat fill. The triangle 510 is above the square 520, and also partially overlaps the square 520. The triangle 510 is partially transparent while the square 520 is fully opaque. The background of page 500 is white.

In the prior art pixel rendering system 100 the controlling program 140 constructs an instruction job wherein the triangle 510 is described by two edges 580 and 585. The first edge 580 is downwards heading, and consists of two segments 581 and 582. The second edge 585 is upwards heading and consists of a single segment. The square 520 is also described by two edges 590 and 595. The first edge 590 is downwards heading, and consists of one segment. The second edge 595 is upwards heading and also consists of one segment only.

The following table shows the edges that the controlling program 160 generates for the objects 510 and 520 in Fig 688277 -16- Object Edges Direction Number of Associated Segments Level Index Square 520 590 Down 1 0 595 Up 1 0 Triangle 510 580 Down 2 1 585 Up 1 1 Table 1 Edges created for objects in Fig. The controlling program 140 generates two level entries in the level table 445 (Fig. 4) for the objects in Fig. 5 as follows: Level Index Associated Fill Index Other Data 0 0 (Fa) 1 1(Fb) Table 2 Level Table created for objects in Fig. Within the instruction job the controlling program 140 generates two fill entries in the fill table 455 (Fig. 4) as follows: Fill Index Name Type Color Opacity Other Data 0 Fa Flat Dark grey 100% 1 Fb Flat Light grey Table 3 Fill Table created for objects in Fig. To understand how the pixel rendering apparatus 180 renders the objects on page 500, consider scanline 531 in Fig. 5. When rendering this scanline 531 no levels are active until segment 581 of edge 580 is encountered. For this reason the colour output by the pixel rendering apparatus 180 is white from the left of the page 500 up until edge 580.

688277 -17- O At edge 580 level 1 is activated. Between edge 580 and edge 590 the active U level list 490 contains only level 1. The colour defined by level l's fill entry is light grey.

Therefore, a span of light grey pixels is output by the pixel rendering apparatus 180 for those pixels between edge 580 and edge 590.

00 5 At edge 590 level 0 is activated. Between edge 590 and edge 585 the active level list 490 contains both level 0 and level 1. The colour defined by level O's fill entry is dark grey and the colour defined by level l's fill entry is light grey. Therefore, a span N of grey pixels is output by the pixel rendering apparatus 180 for the pixels between edge 590 and edge 585, that being the colour that results from compositing the two colours of the objects 510 and 520 using each object's respective level entry to control the proportions of each object's colour.

At edge 585 level 1 is deactivated. Between edge 585 and edge 595 the active level list 490 contains only level 0. The colour defined by level O's fill entry is dark grey.

Therefore, a span of dark grey pixels is output by the pixel rendering apparatus 180 for those pixels between edge 585 and edge 595.

At edge 595 level 0 is deactivated. Between edge 595 and the right hand edge of the page 500 the active level list 490 contains no levels. Therefore a span of white pixels is output by the pixel rendering apparatus 180 for those pixels between edge 595 and the right hand edge of the page 500.

This example shows the basis on which the pixel rendering apparatus 180 works, and shows simple examples of a fill table 455 and a level table 445. In most print jobs the fill table 455 and the level table 445 are far more complex, and typically contain many entries. In complex print jobs the number of entries can be very large, necessitating methods to deal with such table sizes.

688277 -18- Due to the processing load required for pixel compositing placed on the pixel Urendering apparatus 180, the use of the pixel rendering system 100 for low-cost real-time printing on a laser beam printer is unsuitable. The reason is that, when a print system is designed to render in real time, this implies that the worst case instruction job must be S 5 renderable within the time constraints imposed by the print engine speed if a full r- framestore is not to be employed in the printer system 160. Once the paper has started to (Ni roll past the toner drums a laser beam printer may not be stopped in order to allow a rendering engine to catch-up in the generation of pixel data.

In many print jobs (such as text only) there is usually no compositing to be performed and the pixel rendering system 100 is capable of real time rendering without extravagant processing and memory resources in the printer system 160. In a text only page the majority of processing in the pixel rendering apparatus 180 is consumed by edge tracking. In many simple cases where there are no overlapping objects it is not a cost effective solution to provide a printer that is capable of multi-level compositing. The proportion of pages that require compositing will depend on the user's use profile. For the printing of documents that are primarily text the priority determination module 430 will in many cases be running only a trivial single level resolution for each span. A printer with reduced resources (and hence cost) would be capable of rendering such pages in a similar time frame.

However, for very complicated jobs with hundreds of overlapping transparent bitmaps for example, the burden of compositing would require considerable processing and memory resources to be available on the printer system 160 to allow such a page to be rendered in real time. For high page rates and page resolution, the cost of a printer that contains a real time pixel render engine capable of rendering such complicated pages could be prohibitive.

688277 -19- For this reason the provision of the function of compositing in the printer is not U seen as providing a cost effective solution since such a printer would need to handle both the very simple and the very complicated cases with the same low-cost hardware and software resources.

00 5 As described earlier an object's boundaries are decomposed into edges by the controlling program 140. The relative viewing position of each object is explicitly coded (Ni in the level associated with an object's edges and an object's pixel colours are stored in a fill. This information is generated by the controlling program 140 for each object on the page. These edges, levels and fills are then encoded in an instruction job together with other relevant information to be rendered by the pixel rendering apparatus 180.

In some cases an object's edges will be completely obscured by an overlaying opaque object. An object that is fully obscured by an overlying object will not contribute anything to the pixels on a page. In such cases, the edge information, the level and the fill created by the controlling program 140 for the obscured object are redundant in the instruction job. However the controlling program 140 in the pixel rendering system 100 does not discriminate between such obscured objects and objects that are visible on a page, placing all edges levels and fills in the instruction job.

This limitation introduces redundancy in the size of the instruction job created by the controlling program 140 when objects are fully obscured by other objects. This limitation also may introduce redundancy in the size of the instruction job created by the controlling program 140 when objects partially obscure other objects. This redundancy results in a reduction in speed of the subsequent processing of the instruction job. This redundancy also means that the pixel rendering apparatus 180 uses more memory resources than if such redundancy were removed before the instruction job were created.

688277 Whether or not one object partially or fully obscures other objects depends on U the relative positions of the edges of the objects. If the edges of the object should cross one another then the objects can be said to overlap. Furthermore, if edges of objects do not cross at any time, the objects either overlap fully or do not overlap at all. It is only by 00 5 tracking the edges' relative positions that a decision can be made on whether objects overlap fully or not at all. When the number of objects on a page is large the algorithm to determine existence of overlap of each object with all other objects becomes very time consuming. An object by object approach is not feasible since it would involve the repeated tracking of each object's edges as it is compared with all the other objects in a page.

Fig. 2 shows a schematic block diagram of another prior art pixel rendering system 200. The pixel rendering system 200 also comprises a personal computer 210 connected to a printer system 260 through a network 250. The personal computer 210 comprises a host processor 220 for executing a software application 230. The printer system 260 comprises a controller processor 270, memory 290, a pixel rendering apparatus 280, and a printer engine 295 coupled via a bus 275. A controlling program 240 executes on the controller processor 270.

Hence, the pixel rendering system 200 differs from the system 100 shown in Fig.

1 in that the controlling program 240 executes on the controller processor 270 of the printer system 260, instead of on the host processor 220, as is the case in system 100. In system 200 the software application 230 sends a high level description of the page (for example a PDL file) to the controlling program 240 executing in the controller processor 270 of the printer system 260. The controlling program 240 performs the same task as its equivalent controlling program 140 in the system 100 shown in Fig. 1. In system 200 the 688277 -21- O load on the printer system 260 is much greater than the printer system 160 of the system 0 100.

Fig. 3 shows a schematic block diagram of yet another prior art pixel rendering system 300. The pixel rendering system 300 also comprises a personal computer 310 00 5 connected to a printer system 360 through a network 350. The personal computer 310 comprises a host processor 320 for executing a software application 330, a controlling (Ni program 340, and a pixel rendering apparatus 380. The pixel rendering apparatus 380 is Stypically implemented in software executing on the host processor 320, but may also take the form of an ASIC chip executing as a co-processor to the host processor 320. The printer system 360 comprises a controller processor 370, memory 390, and a printer engine 395 coupled via a bus 375. In system 300 the controlling program 340 and the pixel rendering apparatus 380 combine to generate pixels that are delivered to the printer system 360 over the network 350.

The printer system 360 of the host-based printer system 300 may therefore be a candidate for a low-cost printer since it does not implement compositing in the printer system 360, instead requiring that the personal computer 310 implement this function. In the host-based pixel rendering system 300 the page to be printed is rasterised to a bitmap and compressed in the host processor 320 and shipped to the printer system 360 across the network 350.

In the host-based pixel rendering system 300 the main factor that needs to be considered in ensuring that the printer system 360 can maintain real-time printing is the time taken by the controller processor 370 to decompress the compressed bitmap that has been received from the host processor 320 and stored in the memory 390 of the printer system 360. If the bitmap decompression software can run fast enough in the controller processor 370 to ensure that the decompressed pixels are always available to the printer 688277 22 engine 395 when needed, then the printer system 360 is said to be able to print in real O time.

Some remedial action may be taken in the overall host-based pixel rendering system 300 to ensure that real-time printing is guaranteed. For example, the resolution of 00 5 the rasterised bitmap can be reduced for particularly complicated bitmaps that would otherwise not be possible to decompress in real-time in the printer system 360. This (Ni resolution reduction has the net effect of reducing the amount of data that needs to be ihandled by the bitmap decompression software running in the controller processor 370 with a resulting speed up in the rate of pixel generation. Reducing printer resolution reduces the quality of the printed image, a trade-off that must be considered when designing the printer.

Another method of guaranteeing real-time printing is to reduce the speed of the printer rollers. This has the net effect of reducing the rate of pixel consumption by the printer engine 395. The bitmap decompression software running in the printer system 360 can then take more time to decompress while still meeting the real-time deadline of the printer engine 395. While the quality of the page remains unaffected by this action, the printer's slowdown may not be desirable to the user.

In some existing networked host-based printers the controller processor 370 does not start decompressing pixels until such time as the all the compressed pixel data has been received into the printer system 360 over the network 350. The reason for this is to ensure that network latency does not affect the real-time printing guarantee of the printer system 360. If pixel shipping to the printer engine 395 were to commence before the full compressed bitmap were received, then there is the possibility that the network 350 would fail before the full page were received. In this case the printer engine 395 would be starved of data and only a part of the page would be printed. Since the rollers cannot be 688277 23 stopped in laser beam printers once a page has begun to print, the page would be ejected only partially printed.

In choosing to postpone decompression of the compressed bitmap in the printer system 360 until such time as the complete compressed image is received from the host 00 5 processor 320 over the network 350 the printer system 360 must be designed with enough memory 390 to contain the worst case compressed image size possible. The worst case (Ni compressed page size is specified and controlled by the controlling program 340 running in the host processor 320. Lossy compression, resolution reduction and other techniques may be implemented to ensure the worst case page will, when compressed, fit in the memory 390.

In addition, it is desirable that the size of the compressed pixel data be small in order to avoid creating a bottleneck in the network 350. This bottleneck is undesirable because it would adversely affect the overall response time of the network 350 for other users of the network 350 but also because it increases the overall print time as defined as the time between the moment the user commands a page print and the printed page actually is ejected from the printer system 360.

The greatest advantage that the host-based pixel rendering system 300 has over the printer systems 100 and 200 is printer cost because it does not need to implement the time consuming and resource hungry tasks of PDL interpretation, edge tracking, object compositing, colour space conversion and halftoning in the printer itself. However as page resolutions and increased page printing rates are demanded in the future its design places too great a burden both on the network bandwidth and memory requirements necessary to implement a feasible solution.

Thus far, two contrasting printing architectures have been outlined. However, a third form exists whereby an intermediate display list (IDL) is generated on the host and 688277 -24- O then delivered to the printer. This IDL is, in general, bigger than the corresponding PDL O format for the same page but in general is smaller than the typically compressed pixels for that page. By designing the format of the IDL appropriately, the complexity of the printer can be tuned for an optimum cost/performance trade-off in the overall printing system.

00 5 An IDL typically describes the objects on a page in terms of each object's boundary and other attributes of that object such as fill-type that describes the colour or (Ni N colours of the pixels within the object, the relative viewing position of the object and how the object's colours should be combined with the colours of other objects that overlap it.

The printer designed to work with an IDL must contain such software and/or hardware resources on board to allow the decoding of the IDL and the generation of the rasterised pixel data that corresponds to the page. Since an IDL is generally significantly less complex than a full PDL, the resources needed in an IDL-based printer are consequently less than for the PDL equivalent printer. So, in general, an IDL-based printer is generally cheaper than the PDL equivalent printer.

Such an IDL approach has some additional advantages over both the PDL-based and host-based printer systems described above. Firstly, the flexibility in designing the format of an IDL means that computationally intensive tasks may be performed in that part of the printing system that is best suited to executing them. For example, a powerful host computer may be more suited to compositing pixels together rather than performing compositing in the printer itself. A flexible IDL format allows the system designer to balance the processing load between the printer and the host computer by dynamically shifting the processing load from host to printer or vice versa depending on the complexity of the page to be printed.

There are many technical challenges in designing a printer system that successfully balances the load between the host and the printer for a wide range of page 688277 types. It is of the utmost importance that printing quality and printing speed (page rate) U are not compromised in the pursuit of the ideal balance between host and printer. Issues such as cost, quality, software and hardware reuse and immunity to increasing page resolution all need to be addressed in the design of the ideal load-balancing printer 00 5 system.

T Fig. 6 shows a schematic block diagram of a pixel rendering system 600 for (Ni Ci rendering computer graphic object images in accordance with the present invention. The Spixel rendering system 600 comprises a personal computer 610 connected to a printer system 660 through a network 650. The network 650 may be a typical network involving multiple personal computers, or may be a simple connection between a single personal computer and printer system 660.

The personal computer 610 comprises a host processor 620 for executing a software application 630, such as a word processor or graphical software application, and a controlling program 640 in the form of a driver on a WindowsTM or MacintoshTM operating system.

The printer system 660 comprises a controller processor 670, memory 690, a pixel rendering apparatus 680, and a printer engine 695 coupled via a bus 675. The pixel rendering apparatus 680 is in the form of an ASIC card coupled via the bus 675 to the controller processor 670, and the printer engine 695. However, the pixel rendering apparatus 680 may also be implemented in software executed in the controller processor 670.

In the pixel rendering system 600, the software application 630 creates pagebased documents where each page contains objects such as text, lines, fill regions, and image data. The software application 630 sends a page for printing, in the form of an application job, via a graphics application layer to the controlling program 640. In 688277 -26particular, the software application 630 calls sub-routines in a graphics application layer, U such as GDI in WindowsTM, or X-11 in UnixTM, which provide descriptions of the objects Sto be rendered onto the page, as opposed to a raster image to be printed.

The controlling program 640 receives the graphical objects from the application 00 5 program 630, and decomposes the graphical objects into edges, levels and fills in the same manner as the controlling program 140 of the prior art pixel rendering system 100 (Ni (Fig. These edges, levels and fills are called the first set of primitives.

iThe controlling program 640 then further processes this first set of primitives to generate a second set of primitives that facilitates more flexibility in load balancing between the personal computer 610 and printer system 660.

Finally, an instruction job for forwarding to the controlling processor 670 is constructed using the second set of primitives.

The job is then transferred for printing, via the network 650, to the controller processor 670, which controls the pixel rendering apparatus 680. In particular, a program executing on the controller processor 670 is responsible for receiving jobs from the controlling program 640, providing memory 690 for the pixel rendering apparatus 680, initialising the pixel rendering apparatus 680, supplying the pixel rendering apparatus 680 with the start location in memory 690 of the job, and instructing the pixel rendering apparatus 680 to start rendering the job.

The pixel rendering apparatus 680 then interprets the instructions and data in the job, and renders the page without further interaction from the controlling program 640.

The output of the pixel rendering apparatus 680 is colour pixel data, which may be used by the output stage of the printer engine 695.

While object based descriptions are generally used to describe the content of a page to be printed, this choice does not always provide the flexibility to implement 688277 -27optimisations such as removing redundant information from a display list. A typical O driver as found in the prior art personal computer 110 decomposes the objects one by one into primitives that, in the main, represent only that object. Certain optimisations are possible for example the reuse of similar shapes and fill data for the objects but this is 00 5 often not very significant.

Therefore, instead of using an object based description for the page, the pixel rendering system 600 according to the present invention uses the edges of objects as the Sbasis for describing the page. Core to this approach is the concept of an edge behaviour table. The edge behaviour table specifies attributes associated with an edge.

In particular, the edge behaviour table contains one or more entries, each entry containing one or more attributes of the edge to which the entry belongs and also a lifetime for which the attribute or attributes for the edge are active. Table 4 shows an edge behaviour table that has N entries, where each entry has P attributes.

Lifetime Attributel Attribute2 Attribute P Lifetime Valuel Value 12 Valuelp Lifetime 2 Value 21 Value 22 Value 2 p LifetimeN ValueN ValueN2 ValueNp Table 4 Layout of preferred implementation of an Edge Behaviour Table An attribute of an edge is data that is related to that edge. It may be a reference to data used to calculate the pixels following the edge on the page or it may be a function that is used to update the y) position of the edge from scanline to scanline. The attribute may, in fact, be any data that is relevant to the edge.

688277 -28- O While not all possibilities for the attribute of an edge are explicitly described, U one skilled in the art may derive other attributes that are related to an edge as part of a page description used to render a page.

Each edge's attribute also has a lifetime, which is typically expressed in 00 5 scanlines. So, for example, the attributes in one entry of an edge's edge behaviour table that are valid for 25 scanlines would have a lifetime field that indicates this. Depending (Ni on the most optimal solution for the hardware or software platform on which the pixel Srendering apparatus 680 is implemented, the representation of the lifetime of 25 scanlines may be in relative or absolute terms.

In the case of an absolute representation of the lifetime of an edge behaviour table entry, the lifetime is expressed as "from scanline M to scanline N inclusive", where M is the first scanline for which the entry's attributes are valid and N is the last scanline for which the entry's attributes are valid, each scanline value being offset from the start of the page.

In the case of a relative representation of the lifetime of an edge behaviour table entry, the lifetime would be expressed as "25 scanlines". Implied in this representation is that the entry's attributes are valid for 25 scanlines from the start of the edge.

Other expressions are also possible for the lifetime field of each entry in an edge behaviour table. For example an entry that means "for the remainder of the edge" may be used to imply that the corresponding attributes are valid for the remainder of the edge.

While not explicitly mentioned here, those skilled in the art would appreciate that other expressions may be used to code in the lifetime of an edge.

Referring again to the pixel rendering system 600 in Fig. 6, the graphical objects on a page to be printed are passed from the software application 630 to be processed by the controlling program 640. The role of the controlling program is to generate a display 688277 -29- O list that can be rendered by the pixel rendering apparatus 680. Fig. 7 shows a schematic U block diagram of the controlling program 640 in more detail. The controlling program 640 comprises an objects decomposition driver 640a, a primitives processor 640b and an instruction job generator 640c.

00 5 The method employed by the controlling program 640 is to first decompose, using the objects decomposition driver 640a, the page objects passed from the software (Ni application 630 into a representation of edges, levels and fills. As noted above, these Sedges, levels and fills are called the first set of primitives, and are stored in store 640d.

Within the primitives processor 640b, the first set of primitives in store 640d is further processed to generate a second set of primitives placed in store 640e. The second set of primitives consists of edges, an edge behaviour table for every edge and an aggregate fill table. The second set of primitives in store 640e is then further processed by the instruction job generator 640c which creates a display list that can be rendered by the pixel rendering apparatus 680.

Fig. 15a shows a schematic flow diagram of a method 1500, performed by the primitives processor 640b, of generating the second set of primitives from the first set of primitives. This process is known as pre-rendering. It is achieved by determining the active edges on each scanline, and from these active edges, determining the objects that contribute to each pixel on the scanline. The method 1500 determines the active edges on any scanline from the main edge list in the first set of primitives in store 640d. The main edge list contains all the edges to be rendered on the page sorted in ascending order of their starting scanline (y-order), and the active edge list (ActiveEdgeList) is a temporary list of edges that intersect the current scanline.

The method 1500 starts in step 1550 where a variable CurY is set to zero and the active edge list is set to an empty set. Then, in step 1551, the primitives processor 640b 688277 reads an edge from the main edge list. The primitives processor 640b next determines in 0 step 1552 whether all the edges in the main edge list have been processed, or whether the y-value of the currently-read edge, having variable name currentedge.y, is greater than the value stored in the variable CurY. If neither of these conditions is satisfied then the 00 5 method 1500 proceeds to step 1553 where the primitives processor 406b removes the 0 current edge from the main edge list. The current edge is also merged into the active edge list. Edges in the active edge list are ordered by ascending x-value; i.e. the order along the scanline. Once the current edge is merged into the active edge list the method 1500 returns to step 1551 where the next edge is read from the main edge list.

If it is determined in step 1552 that either of the conditions is satisfied, then in step 1554 the primitives processor 640b determines a number N of scanlines to prerender. If all the edges in the main edge list have been processed then the number N is set to the number of scanlines remaining on the page; i.e. the difference between the page height and the current scanline CurY as follows: N PageHeight CurY (1) If, however, there are still edges in the main edge list to process, then the number N is set to the number of scanlines between the current scanline CurY and the scanline on which the currently-read edge commences: N current_edge.y CurY (2) Once the number N of scanlines has been determined in step 1554 the primitives processor 640b pre-renders the active edge list for N scanlines in step 1555. The prerendering of the N scanlines in step 1555 is described in more detail with reference to Fig.

The primitives processor 640b then updates the current scanline CurY in step 1556 using the equation: 688277 -31 o CurY CurY N (3) Next, in step 1557, the primitives processor 640b determines whether the updated current scanline CurY is equal to the page height. If so, the method 1500 terminates in step 1558. Alternatively, if it is determined in step 1557 that the current scanline CurY is less than the page height then the method 1500 returns to step 1551 from where the next edge from the main edge list is processed.

(Ni Step 1555 of pre-rendering a scanline is now described in more detail with C reference to Fig. 15b wherein a schematic flow diagram of step 1555 is shown. Step 1555 starts in an initialising sub-step 1561 wherein the primitives processor 640b sets a temporary active edge list (TempAEL) to an empty set and also sets the active level list (ActiveLevelList) and a last active level list (LastActiveLevelList) to empty sets. Sub-step 1562 follows where the primitives processor 640b determines whether the active edge list is empty, hence whether all edges in the active edge list have been processed.

If it is determined that the active edge list still contains entries then step 1555 continues to sub-step 1563 where the next edge along the scanline is read from the active edge list and that edge is removed from the active edge list. Also, the level or levels pointed to by that edge are activated or deactivated as appropriate. If a level or levels are activated they are added to the active level list. Otherwise if the level or levels are deactivated they are removed from the active level list. Then, in sub-step 1564, the primitives processor 640b pre-renders the current edge using the active level list. Substep 1564 is described in more detail with reference to Fig. 15c. Sub-step 1565 follows sub-step 1564 where the active level list is copied into the last active level list. In substep 1566 the x-position of the edge (Edge.x) is updated for this edge for the next scanline.

688277 -32- In sub-step 1567 the primitives processor 640b then determines whether the edge Sexpires, in other words, terminates. If the edge terminates then the step 1555 returns to sub-step 1562. Alternatively, if it is determined in sub-step 1567 that the edge does not terminate then that edge is added to the temporary active edge list based on the updated x- 00 5 position in step 1568 before the step 1555 returns to sub-step 1562.

From sub-step 1562 any subsequent edges on the scanline are processed until it is determined in sub-step 1562 that the active edge list is empty. Step 1555 then proceeds N to sub-step 1570 where the temporary active edge list is copied into the active edge list.

The primitives processor 640b then determines in sub-step 1571 whether more scanlines need to be pre-rendered. If not then the step 1555 returns in sub-step 1572 back to step 1556 in Fig 15a. Alternatively, if it is determined that more scanlines have to be prerendered, then the step 1555 returns to sub-step 1561.

Sub-step 1564 of pre-rendering an edge using the active level list and the last active level list is now described in more detail with reference to Fig. 15c wherein a schematic flow diagram of sub-step 1564 is shown. Sub-step 1564 starts in sub-step 1580 where the primitives processor 640b determines whether the active level list is empty. If the active level list is determined to be empty, then the primitives processor 640b searches the aggregate fill table in sub-step 1581 for an entry that corresponds to no levels being active. If such an entry does not exist in the aggregate fill table then one is added to the aggregate fill table in sub-step 1582.

If it is determined in sub-step 1580 that the active level list is not empty, the substep 1564 proceeds to sub-step 1584 where the active level list is sorted by descending priority order. The number of entries in the active level list is NumLevels. In sub-steps 1585, 1586, 1587 and 1588, the primitives processor 640b determines the highest level (Lvl) in the active level list that is opaque when the objects are viewed from above. In 688277 -33- O step 1589 the aggregate fill table is searched for an entry that corresponds to the level Lv 0 and all levels above it being active. If such an entry does not exist in the aggregate fill Stable then one is added to the aggregate fill table in sub-step 1590.

From sub-step 1581 if an entry exists in the aggregate fill table that corresponds 00 5 to no levels being active, from sub-step 1589 if an entry exists in the aggregate fill table that corresponds to the level Lv and all levels above it being active, or from sub-step (Ni N 1582 or 1590 after an entry as been added to the aggregate fill table, sub-step 1564 Scontinues to sub-step 1591 where a variable AFTEntry (Aggregate Fill Table Entry) is set to be equal to the entry in the aggregate fill table that has just been found or just been added. Also, a hidden flag variable is set to be TRUE if the aggregate fill table entry corresponding to the span before this edge is the same as the aggregate fill table entry corresponding to the span following this edge. The hidden flag variable is set to be FALSE if the aggregate fill table entry corresponding to the span before this edge is different to the aggregate fill table entry corresponding to the span following this edge.

In sub-step 1592 the edge behaviour table for this edge is updated with the AFTEntry variable and the hidden flag variable. Sub-step 1592 is described in more detail with reference to Fig. 15d. Finally, sub-step 1564 ends in sub-step 1593 where a return is made to sub-step 1565 in Fig. Sub-step 1592 of updating the edge behaviour table for a particular edge is now described in more detail with reference to Fig. 15d wherein a schematic flow diagram of sub-step 1592 is shown. In the preferred implementation each edge behaviour table contains two attributes. The first attribute is a reference to the aggregate fill table entry that is used to determine the pixels following an edge in the x-direction along a scanline.

The second attribute is a hidden flag that indicates that an edge does not change the aggregate fill table entry that is active before the edge. In this sense the edge is hidden.

688277 -34- Sub-step 1592 starts in sub-step 1540 where the primitives processor 640b determines U whether an edge behaviour table exists for the edge.

If it is determined that an edge behaviour table does not exist for the given edge, then an empty edge behaviour table is created in sub-step 1544 and a variable i is set to 0 5 1. Sub-step 1545 then follows where an entry is added to the edge behaviour table at r index i+1 (becoming index 0 or the first entry in this case). The first attribute of the entry (Ni at index i+1 is then set to be a reference to the aggregate fill table entry (AFTEntry) for Sthis edge on this scanline as determined in step 1591 of the schematic flow diagram shown in Fig. 15c. Also in sub-step 1545 the hidden flag for this edge on this scanline as determined in step 1591 of the schematic flow diagram shown in Fig. 15c is added to this entry in the edge behaviour table as attribute 2. The lifetime field of the just-added edge behaviour table entry is initialised to 1. Sub-step 1592 ends in sub-step 1546 where a return is made to sub-step 1593 in Fig. If it is determined in sub-step 1540 that an edge behaviour table exists for the edge then in sub-step 1541 the variable i is set to be the index of the last entry in the edge's edge behaviour table. Sub-step 1542 then follows where the primitives processor 640b determines whether there has been any change from the previous scanline in the attributes of this edge. If there has been no change then the lifetime field of this entry is incremented in sub-step 1543. Sub-step 1592 then ends in sub-step 1546.

Alternatively, if it is determined in sub-step 1542 that there has indeed been a change in the attributes of the edge from the last scanline to this scanline, then a new entry is added to the edge behaviour table in sub-step 1545 and the new attributes are added. The lifetime field of the just-added edge behaviour table entry is initialised to 1.

Sub-step 1592 then ends in sub-step 1546.

688277 O In this manner when all the edges have been tracked down the page the aggregate Sfill table contains an entry for each unique combination of levels (and, by reference, the fills associated with these levels) that have been encountered on the page. In addition an edge behaviour table is created for each edge and these tables are populated with the 00 5 aggregate fill table entry attribute and the hidden flag attribute.

Table 5 shows the layout of the preferred implementation of the aggregate fill (Ni table as created by the process described above. In this example the table is shown to contain the levels and fills. However it is also possible for the table to instead contain references to the levels and fills.

Index Contents 0 [active level(s) and associated fill(s)] 0 1 [active level(s) and associated fill(s)]l 2 [active level(s) and associated fill(s)] 2 N [active level(s) and associated fill(s)]N Table 5 Aggregate Fill Table created for a page Table 6 shows the preferred implementation of an edge behaviour table.

688277 -36- Lifetime Attribute 1 Attribute 2 (aggregate fill index) (hidden flag) Lifetime, aggregate fill indexi TRUE/FALSE Lifetime 2 aggregate fill indexk TRUE/FALSE Lifetime 3 aggregate fill index 1

TRUE/FALSE

For the remainder aggregate fill indexz TRUE/FALSE of the edge Table 6 edge behaviour table in the preferred implementation Once all the edges in the first set of primitives in store 640d (Fig. 7) have been processed in the manner described above the primitives processor 640b adds the following to the second set of primitives in store 640e: the aggregate fill table containing all the aggregate fills that occur on the page; and the edge behaviour table for each edge in the first set of primitives.

In addition the primitives processor 640b generates edges in the second set of primitives by making copies of the edges in the first set of primitives with the following exceptions: edges in the first set of primitives whose associated edge behaviour table has the hidden attribute as always TRUE will not appear in the second set of primitives; and if an edge in the first set of primitives has two or more segments that run for scanlines that fall within an entry whose hidden attribute is TRUE then those two or more segments are replaced by one straight line segment in the second set of primitives.

688277 -37- O It is noted that an edge behaviour table in this description has two attributes.

0 However, a person skilled in the art would understand that other attributes are possible.

The primitives processor 640b may optionally further process the aggregate fill table in the second set of primitives in store 640e. This processing may take the form of 00 5 actually compositing together the level(s) (and, by reference, the fill(s)) that constitute an aggregate fill. The result of such a compositing operation may be a single flat colour or a (Ni Sbitmap or any other representation that allows the pixel rendering apparatus 680 to render Sthe pixels in the spans.

For example, if an entry in the aggregate fill table contains the levels and fills of ten objects, the primitives processor 640b may optionally composite these levels and fills to a single data set that specifies the actual pixel colours within that region.

The format of the aggregate fill table depends to a great extent on the capability of the printer in the printing system 660 being considered. In the case where the printer cannot implement compositing then the aggregate fill table will be processed by the primitives processor 640b to contain data sets that contain opaque pixels for every region on the page.

If, on the other hand, the printer is capable of compositing then the aggregate fill table need not perform any compositing and may leave the aggregate fill table entries containing essentially all the level(s) and fill(s) that originated in the first set of primitives in store 640d.

This flexibility is a powerful advantage of the pixel rendering system 600 over the pixels rendering systems 100, 200, and 300.

Once the second set of primitives in store 640e have been generated by the primitives processor 640b, in the preferred implementation an instruction job is created by the instruction job generator 640c. The instruction job created contains the aggregate fill 688277 -38 O table, the edges and the edge behaviour tables of the second set of primitives in store U 640e. The instruction job also contains instructions that allow the pixel rendering apparatus 680 to render the page using these primitives.

To further illustrate how the primitives processor 640b generates the second set 00 5 of primitives in store 640e for a variety of object configurations, a number of examples are next described. In each of the following examples the aggregate fill table has been (Ni expanded for clarity purposes to give details of the fill that would result from compositing Stogether the level(s) and fill(s) in each entry.

In a first example a single object is processed. Fig. 8 illustrates a square 810 with a dark grey flat fill of 50% transparency on page 800 having a white background. In the pixel rendering system 600 the controlling program 640 constructs an instruction job wherein the square 810 is described by two edges as follows: edge 820 (with one segment) and an associated edge behaviour table; and edge 830 (with one segment) and an associated edge behaviour table.

It is noted that in contrast to the prior art pixel rendering system 100 the edges are not classified as upward heading or downward heading.

Object Edges Number of Segments Square 810 820 1 830 1 Table 7 Edges created for object 810 in Fig. 8 Within the instruction job the controlling program 640 generates two entries in the aggregate fill table as follows: 688277 -39- Index Name Type Colour Opacity Created from 0 Fw Flat White 100% Background White 1 Fa Flat Light 100% Square 810 dark grey composited grey with background white Table 8 Aggregate Fill Table created for object 810 in Fig. 8 Within the instruction job the controlling program 640 generates an edge behaviour table for each edge. The edge behaviour table for edge 820 is generated by considering that, in Fig. 8, from scanline 840 until the end of edge 820 at scanline 850, fill Fa, the dark grey of the square 810, should be used by the pixel rendering apparatus 680 to generate the pixel colour for those pixels following edge 820 in x-raster order until another edge is encountered on the scanline or the edge of the page is reached.

Entry Lifetime (Relative) Attribute 1 Attribute 2 (aggregate fill index) (hidden flag) For the remainder of the edge Index 1 (Fa) FALSE Table 9 Edge Behaviour Table for edge 820 in Fig. 8 Similarly, the edge behaviour table for edge 830 is generated by considering that, from scanline 840 until the end of edge 830 at scanline 850, fill Fw, the white colour used as the page background, should be used by the pixel rendering apparatus 680 to generate the pixel colour for those pixels following edge 830 in x-raster order until another edge is encountered on the scanline or the edge of the page is reached.

Entry Lifetime (Relative) Attribute 1 Attribute 2 (aggregate fill index) (hidden flag) For the remainder of the edge Index 0 (Fw) FALSE Table 10 Edge Behaviour Table for edge 830 in Fig. 8 688277 (Ni U In a second example opaque overlapping objects are processed. Fig. 10 shows Stwo graphical objects: a triangle 1010 with a light grey flat fill, and a square 1020 with a dark grey flat fill. Triangle 1010 is above square 1020, and also partially overlaps square 00 5 1020. Both triangle 1010 and square 1020 are fully opaque. However, for the purposes of explanation the hidden portion of square 1020 is shown in Fig. 10. The background of (Ni Nthe page 1000 is white.

SIn the pixel rendering system 600 the controlling program 640 constructs an instruction job wherein the triangle 1010 is described by two edges: edge 1030 (with two segments) and an associated edge behaviour table; and edge 1040 (with one segment) and an associated edge behaviour table.

In addition the square 1020 is described by two edges: edge 1050 (with one segment) and an associated edge behaviour table; and edge 1060 (with one segment) and an associated edge behaviour table.

It is once again noted that in contrast to the prior art pixel rendering system 100 the edges are not classified as upward heading or downward heading.

Object Edges Number of Segments Triangle 1010 1030 2 1040 1 Square 1020 1050 1 1060 1 Table 11: Edges created for objects in Fig. Within the instruction job the controlling program 640 generates three entries in the aggregate fill table as follows: 688277 -41- Index Name Type Colour Opacity Created from 0 Fw Flat White 100% Background White 1 Fa Flat Light grey 100% Triangle 1010 light grey 2 Fb Flat Dark grey 100% Square 1020 dark grey fill Table 12 Aggregate Fill Table created for objects in Fig. Within the instruction job the controlling program 640 generates an edge behaviour table for each edge. Starting with edge 1030, from scanline 1070 until the end of edge 1030, fill Fa, the light grey colour of triangle 1010, is to be used by the pixel rendering apparatus 680 to generate the pixel colour for those pixels following edge 1030 in x-raster order until another edge is encountered on the scanline or the edge of the page is reached.

Entry Lifetime (Relative) Attribute 1 Attribute 2 (aggregate fill index) (hidden flag) For the remainder of the edge Index 1 (Fa) FALSE Table 13 Edge Behaviour Table for edge 1030 in Fig. For edge 1040, from scanline 1070 until scanline 1080, fill Fw, the white colour used as the page background, is added to the edge behaviour table by the controlling program 640 to indicate that that fill is to be used for those pixels following edge 1040 in x-raster order until another edge is encountered on the scanline or the edge of the page is reached.

Also, from scanline 1080 until scanline 1095, fill Fb, the dark grey colour of square 1020, is to be used by the pixel rendering apparatus 680 to generate the pixel colour for those pixels following edge 1040 in x-raster order until another edge is encountered on the scanline or the edge of the page is reached.

688277 -42- O From scanline 1095 until the end of edge 1040, fill Fw, the white colour used as 0 the page background, is to be used by the pixel rendering apparatus 680 to generate the pixel colour for those pixels following edge 1040 in x-raster order until another edge is encountered on the scanline or the edge of the page is reached.

00

OO

t^q m

(N

O t1- Entry Lifetime (Relative) Attribute 1 Attribute 2 (aggregate fill index) (hidden flag) scanline 1070 to scanline 1080 Index 0 (Fw) FALSE scanline 1080 to scanline 1095 Index 2 (Fb) FALSE For the remainder of the edge Index 0 (Fw) FALSE Table 14 Edge Behaviour Table for edge 1040 in Fig. Considering edge 1050 of the square 1020 next, from scanline 1080 to scanline 1090 edge 1050 does not contribute to the pixel values on the page. For this reason the controlling program 640 sets its hidden flag attribute to TRUE. The aggregate fill index for this entry will disregarded by the renderer but is preferably set to indicate the fill of the pixel span following the edge (in this case Fa).

From scanline 1090 until the end of edge 1050, fill Fb, the dark grey colour of square 1020, is added to the edge behaviour table by the controlling program 640 to indicate that that fill is to be used for those pixels following edge 1050 in x-raster order until another edge is encountered on the scanline or the edge of the page is reached.

Table 15 Edge Behaviour Table for edge 1050 in Fig. 688277 -43- For edge 1060, from scanline 1080 until the end of edge 1060, fill Fw, the white U colour used as the page background, is to be used by the pixel rendering apparatus 680 to generate the pixel colour for those pixels following edge 1060 in x-raster order until another edge is encountered on the scanline or the edge of the page is reached.

00 Entry Lifetime (Relative) Attribute 1 Attribute 2 (aggregate fill index) (hidden flag) For the remainder of the edge Index 0 (Fw) FALSE Table 16 Edge Behaviour Table for edge 1060 in Fig. In a third example, an object is completely hidden by an overlapping opaque object. Fig. 9 illustrates two graphical objects: a rectangle 910 with a dark grey flat fill, and a smaller rectangle 920 with a light grey flat fill. Both rectangle 910 and rectangle 920 are fully opaque, and rectangle 910 completely obscures rectangle 920, which is shown in dashed outline. The background page 900 is white.

In the pixel rendering system 600 the controlling program 640 constructs an instruction job wherein rectangle 910 is described by two edges: edge 930 (with one segment) and an associated edge behaviour table; and edge 940 (with one segment) and an associated edge behaviour table.

Rectangle 920 is also described by two edges: edge 950 (with one segment) and an associated edge behaviour table.

edge 960 (with one segment) and an associated edge behaviour table.

It is again noted that in contrast to the prior art pixel rendering system 100 the edges are not classified as upward heading or downward heading.

688277 -44- Object Edges Number of Segments Rectangle 910 930 1 940 1 Rectangle 920 950 1 960 1 Table 17 Edges created for objects in Fig. 9 Within the instruction job the controlling program 640 generates two entries in the aggregate fill table as follows: Index Name Type Colour Opacity Created from 0 Fw Flat White 100% Background White 1 Fa Flat Dark grey 100% Rectangle 910 fill colour Table 18 Aggregate Fill Table created for objects in Fig. 9 Within the instruction job the controlling program 640 generates an edge behaviour table for each edge. For the edge behaviour table for edge 930 it is considered that, from scanline 970 until the end of edge 930 at scanline 985, fill Fa, the dark grey of rectangle 910, should be used by the pixel rendering apparatus 680 to generate the pixel colour for those pixels following edge 930 in x-raster order until another edge is encountered on the scanline or the edge of the page is reached.

Entry Lifetime (Relative) Attribute 1 Attribute 2 (aggregate fill index) (hidden flag) For the remainder of the edge Index 1 (Fa) FALSE Table 19 Edge Behaviour Table for edge 930 in Fig. 9 688277 O In generating the edge behaviour table for edge 940, from scanline 970 until the U end of edge 940 at scanline 985, fill Fw, the white colour used as the page background, should be used by the pixel rendering apparatus 680 to generate the pixel colour for those pixels following edge 940 in x-raster order until another edge is encountered on the 0 5 scanline or the edge of the page is reached.

Entry Lifetime (Relative) Attribute 1 Attribute 2 (aggregate fill index) (hidden flag) For the remainder of the edge Index 0 (Fw) FALSE Table 20 Edge Behaviour Table for edge 940 in Fig. 9 Next, considering the edge 950, from the start of edge 950 on scanline 975 until the end of edge 950 at scanline 980, the fill Fa, the dark grey of rectangle 910, should be used by the pixel rendering apparatus 680 to generate the pixel colour for those pixels following edge 950 in x-raster order until another edge is encountered on the scanline or the edge of the page is reached. However, since this fill is identical to the fill preceding edge 950, edge 950 does not contribute to the pixel values on the page. For this reason the controlling program 640 sets the hidden flag attribute of edge 950 to TRUE over its whole extent.

Entry Lifetime (Relative) Attribute 1 Attribute 2 (aggregate fill index) (hidden flag) For the remainder of the edge Index 1 (Fa) TRUE Table 21 Edge Behaviour Table for edge 950 in Fig. 9 Finally, for the edge behaviour table for edge 960, from scanline 975 until the end of edge 960 at scanline 980, fill Fa, the dark grey of rectangle 910, should be used by the pixel rendering apparatus 680 to generate the pixel colour for those pixels following edge 930 in x-raster order until another edge is encountered on the scanline or the edge of 688277 -46the page is reached. However, since this fill is identical to the fill preceding edge 960, U edge 960 does not contribute to the pixel values on the page. For this reason the controlling program 640 sets the hidden flag attribute of edge 960 to TRUE over its whole extent.

00 Entry Lifetime (Relative) Attribute 1 Attribute 2 (aggregate fill index) (hidden flag) For the remainder of the edge Index 1 (Fa) TRUE

N'

5 Table 22 Edge Behaviour Table for edge 960 in Fig. 9 Neither the left edge 950 nor the right edge 960 of rectangle 920 appear in the final instruction job created by the controlling program 640 since they do not contribute any pixel colour information over their whole extents. Therefore it is seen that the decomposition of objects into edges and associated edge behaviour tables in the pixel rendering system 600 has the advantage over the pixel rendering system 100 that noncontributing edges and invisible fills do not appear in the instruction job.

In a fourth example the processing of semi transparent flat fill overlapping objects is considered. Fig. 11 shows two graphical objects: a triangle 1110 with a light grey flat fill, and a square 1120 with a dark grey flat fill. Triangle 1110 is above square 1120, and also partially overlaps square 1120. Triangle 1110 is partially transparent while square 1120 is fully opaque. The background of the page 1100 is white.

In the pixel rendering system 600 the controlling program 640 constructs an instruction job wherein the triangle 1110 is described by two edges: edge 1130 (with two segments) and an associated edge behaviour table; and edge 1140 (with one segment) and an associated edge behaviour table.

In addition the square 1120 is described by two edges: edge 1150 (with one segment) and an associated edge behaviour table; and 688277 -47edge 1160 (with one segment) and an associated edge behaviour table.

It is yet again noted that in contrast to the prior art pixel rendering system 100 the edges are not classified as upward heading or downward heading.

Object Edges Number of Segments Triangle 1110 1130 2 1140 1 Square 1120 1150 1 1160 1 Table 23 Edges created for objects in Fig. 11 The controlling program 640 generates four entries in the aggregate fill table as follows: Index Name Type Colour Opacity Created from 0 Fw Flat White 100% Background White 1 Fa Flat Light grey 100% Triangle 1110's fill composited with background white 2 Fb Flat Dark grey 100% Square 1120's dark grey fill 3 Fc Flat Grey 100% Triangle 1110's light grey fill composited with square 1120's dark grey fill Table 24 Aggregate Fill Table created for objects in Fig. 11 Within the instruction job the controlling program 640 then generates an edge behaviour table for each edge. For edge 1130, from scanline 1170 to scanline 1185 fill Fa, the light grey of the triangle 1110, is added to the edge behaviour table by the 688277 -48controlling program 640 to indicate that that fill is to be used for those pixels following 0 edge 1130 in x-raster order until another edge is encountered on the scanline.

From scanline 1185 to scanline 1190 fill Fc, the grey color that results from compositing fill Fa and fill Fb, is added to the edge behaviour table by the controlling 00 5 program 640 to indicate that that fill is to be used for those pixels following edge 1130 in x-raster order until another edge is encountered on the scanline.

From scanline 1190 until the end of edge 1130, fill Fa, the light grey of the triangle 1120, is added to the edge behaviour table by the controlling program 640 to indicate that that fill is to be used for those pixels following edge 1130 in x-raster order until another edge is encountered on the scanline.

Entry Lifetime (Relative) Attribute 1 Attribute 2 (aggregate fill index) (hidden flag) scanline 1170 to scanline 1185 Index 1 (Fa) FALSE scanline 1185 to scanline 1190 Index 3 (Fc) FALSE For the remainder of the edge Index 1 (Fa) FALSE Table 25 Edge Behaviour Table for edge 1130 in Fig. 11 Considering edge 1140 next, from scanline 1170 to scanline 1175 fill Fw, the white colour used as the page background, is added to the edge behaviour table by the controlling program 640 to indicate that that fill is to be used for those pixels following edge 1140 in x-raster order.

From scanline 1175 to scanline 1190 fill Fb, the dark grey colour of square 1120, is added to the edge behaviour table by the controlling program 640 to indicate that that fill is to be used for those pixels following edge 1140 in x-raster order until another edge is encountered on the scanline.

688277 -49- S Finally, from scanline 1190 until the end of edge 1140, fill Fw, the white colour 0 used as the page background, is again added to the edge behaviour table by the controlling program 640 to indicate that that fill is to be used for those pixels following edge 1140 in x-raster order.

00 Entry Lifetime (Relative) Attribute 1 Attribute 2 (aggregate fill index) (hidden flag) scanline 1170 to scanline 1175 Index 0 (Fw) FALSE scanline 1175 to scanline 1190 Index 2 (Fb) FALSE For the remainder of the edge Index 0 (Fw) FALSE Table 26 Edge Behaviour Table for edge 1140 in Fig. 11 For edge 1150, from scanline 1175 to scanline 1185 fill Fc, the grey colour that results from compositing fill Fa and fill Fb, is added to the edge behaviour table by the controlling program 640 to indicate that that fill is to be used for those pixels following edge 1150 in x-raster order until another edge is encountered on the scanline.

Also, from scanline 1185 until the end of edge 1150, fill Fb, the dark grey colour of square 1120, is added to the edge behaviour table by the controlling program 640 to indicate that that fill is to be used for those pixels following edge 1150 in x-raster order until another edge is encountered on the scanline.

Table 27 Edge Behaviour Table for edge 1150 in Fig. 11 688277 O Finally, for edge 1160 of square 1120, from scanline 1170 until the end of edge 0 1160, fill Fw, the white colour used as the page background, is added to the edge behaviour table by the controlling program 640 to indicate that that fill is to be used for those pixels following edge 1160 in x-raster order.

00

C',

Entry Lifetime (Relative) Attribute 1 Attribute 2 (aggregate fill index) (hidden flag) For the remainder of the edge Index 0 (Fw) FALSE

N~

5 Table 28 Edge Behaviour Table for edge 1160 in Fig. 11 In a final and fifth example, the processing of semi transparent non-flat fill overlapping objects are considered. Fig. 12 shows two graphical objects: a triangle 1210 with a source bitmap fill at 121dpi, and a square 1220 with another source bitmap fill at 300dpi. Triangle 1210 is above square 1220, and also partially overlaps square 1220.

Triangle 1210 is partially transparent while square 1220 is fully opaque. The background of the page 1200 is white.

In the pixel rendering system 600 the controlling program 640 constructs an instruction job wherein the triangle 1210 is described by two edges: edge 1230 (with two segments) and an associated edge behaviour table; and edge 1240 (with one segment) and an associated edge behaviour table.

Square 1220 is also described by two edges: edge 1250 (with one segment) and an associated edge behaviour table; and edge 1260 (with one segment) and an associated edge behaviour table.

688277 -51 Object Edges Number of Segments Triangle 1210 1230 2 1240 1 Rectangle 1220 1250 1 1260 1 Table 29 Edges created for objects in Fig. 12 Within the instruction job the controlling program 640 the aggregate fill table as follows: generates four entries in Index Name Type Colour Resolution Opacity Created from 0 Fw Flat White 100% Background White 1 Fa Bitmap 121dpi 100% Triangle 1210's bitmap fill composited with background white 2 Fb Bitmap 300dpi 100% Square 1220's bitmap fill 3 Fc Bitmap Page 100% Triangle 1210's bitmap Resolution fill composited with square 1220's bitmap fill Table 30 Aggregate Fill Table created for objects in Figure 12 The pixels that comprise Fill Fc are calculated in the controlling program 640 as follows: The contribution of triangle 1210 to each pixel within the region of overlap of triangle 1210 and square 1220 is calculated by transforming the source bitmap for triangle 1210 to page resolution, using an appropriate affine transformation and a method of 688277 -52interpolation such as nearest neighbour, bilinear or bi-cubic, or any other method of 0 image interpolation.

The contribution of square 1220 to each pixel within the region of overlap of triangle 1210 and square 1220 is calculated by transforming the source bitmap for square 00 5 1220 also to page resolution, again using an appropriate affine transformation and a r- method of interpolation as above.

SThe contributions from triangle 1210 and square 1220 are then composited 0 together using the specified compositing operation (such as a binary raster operation to produce a new bitmap at page coordinates. This composited bitmap defines the pixels within the region of overlap of triangle 1210 and square 1220.

Depending on their sizes, bitmap fills, Fa, Fb and Fc, may be compressed using a suitable compression algorithm before they are inserted into the instruction job by the controlling program 640.

In addition, the composited fills may first be additionally processed to reduce the processing load on the pixel rendering apparatus 680. Examples of such processing include halftoning for bitmap fills at page coordinates, colour space conversion for any fill types or other relevant processing.

The controlling program 640 then generates an edge behaviour table for each edge.

For edge 1230, from scanline 1270 to scanline 1280 fill Fa, the bitmap of triangle 1210 at 121dpi composited with the background white of the page 1200, is added to the edge behaviour table by the controlling program 640 to indicate that that fill is to be used for those pixels following edge 1230 in x-raster order until another edge is encountered on the scanline.

688277 -53- O Also, from scanline 1280 to scanline 1285 fill Fc, the bitmap at page resolution

(N

0 that results from compositing triangle 1210 and square 1220 in the region of overlap of triangle 1210 and square 1220, is added to the edge behaviour table by the controlling program 640 to indicate that that fill is to be used for those pixels following edge 1230 in 00 5 x-raster order until another edge is encountered on the scanline.

Finally, from scanline 1285 until the end of edge 1230 fill Fa, the bitmap of triangle 1210 at 121dpi composited with the background white of the page 1200, is added to the edge behaviour table by the controlling program 640 to indicate that that fill is to be used for those pixels following edge 1230 in x-raster order until another edge is encountered on the scanline.

Entry Lifetime (Relative) Attribute 1 Attribute 2 (aggregate fill index) (hidden flag) scanline 1270 to scanline 1280 Index 1 (Fa) FALSE scanline 1280 to scanline 1285 Index 3 (Fc) FALSE For the remainder of the edge Index 1 (Fa) FALSE Table 31 Edge Behaviour Table for edge 1230 in Fig. 12 For edge 1240 of triangle 1210, from scanline 1270 to scanline 1275 fill Fw, the white colour used as the page background, is added to the edge behaviour table by the controlling program 640 to indicate that that fill is to be used for those pixels following edge 1240 in x-raster order.

For the part of edge 1240 from scanline 1275 to scanline 1285 fill Fb, the bitmap of square 1220 at 300dpi, is added to the edge behaviour table by the controlling program 640 to indicate that that fill is to be used for those pixels following edge 1240 in x-raster order until another edge is encountered on the scanline.

688277 -54- Finally, from scanline 1285 until the end of edge 1240, fill Fw, the white color 0 used as the page background, is added to the edge behaviour table of edge 1240 by the controlling program 640 to indicate that that fill is to be used for those pixels following edge 1240 in x-raster order.

0O 1o%

O

0 Entry Lifetime (Relative) Attribute 1 Attribute 2 (aggregate fill index) (hidden flag) scanline 1270 to scanline 1275 Index 0 (Fw) FALSE scanline 1275 to scanline 1285 Index 2 (Fb) FALSE For the remainder of the edge Index 0 (Fw)

FALSE

Table 32 Edge Behaviour Table for edge 1240 in Fig. 12 Next, for edge 1250 of square 1220, from scanline 1275 to scanline 1280 fill Fc, the bitmap at page resolution that results from compositing triangle 1210 and square 1220 in the region of overlap of triangle 1210 and square 1220, is added to the edge behaviour table of edge 1250 by the controlling program 640 to indicate that that fill is to be used for those pixels following edge 1250 in x-raster order until another edge is encountered on the scanline.

For the part of edge 1250 from scanline 1280 until the end of edge 1250, fill Fb, the bitmap of square 1220 at 300dpi, is added to the edge behaviour table of edge 1250 by the controlling program 640 to indicate that that fill is to be used for those pixels following edge 1250 in x-raster order until another edge is encountered on the scanline.

688277 Entry Lifetime (Relative) Attribute 1 Attribute 2 (aggregate fill index) (hidden flag) scanline 1275 to scanline 1280 Index 3 (Fc) FALSE For the remainder of the edge Index 2 (Fb) FALSE Table 33 Edge Behaviour Table for edge 1250 in Fig. 12 For edge 1260, from scanline 1275 until the end of edge 1260, fill Fw, the white colour used as the page background, is added to the edge behaviour table of edge 1260 by the controlling program 640 to indicate that that fill is to be used for those pixels following edge 1260 in x-raster order.

Entry Lifetime (Relative) Attribute 1 Attribute 2 (aggregate fill index) (hidden flag) For the remainder of the edge Index 0 (Fw) FALSE Table 34 Edge Behaviour Table for edge 1260 in Fig. 12 That concludes the examples to illustrate how the primitives processor 640b generates the second set of primitives. In the examples the aggregate fill table entries have contained the result of compositing the contribution of the active fills. However it is not a requirement for that compositing to be performed by the primitives processor 640b.

When the controlling program 640 has built the instruction job, the job is transferred to the controlling processor 670 of the printer system 660. The controlling processor 670 initialises the pixel rendering apparatus 680, supplies the starting location of the instruction job, and instructs the pixel rendering apparatus 680 to render the job.

Fig. 13 shows a more detailed schematic'block diagram of the pixel rendering apparatus 680 shown in Fig. 6. The pixel rendering apparatus 680 comprises an instruction execution module 1310; an edge tracking module 1320; an edge behaviour 688277 -56- O table decoding module 1330; a pixel generation module 1340; and a pixel output module O 1350, arranged in a pipeline.

The instruction execution module 1310 reads and processes instructions from the instruction job and formats the instructions into messages that are transferred to the other 00 5 modules 1320 to 1350 within the pipeline. The edge tracking module 1320 is responsible for determining the edge that bounds the span of the currently scanned pixel using an active edge list 1370 that it maintains, and passes this information onto the edge Sbehaviour table decoder module 1330. The edge behaviour table decoder 1330 module is pre-loaded with the edge behaviour tables 1375 from the instruction job. The edge behaviour table decoder 1330 uses the corresponding edge behaviour table to determine whether or not the edge is hidden on a scanline and, if not, what aggregate fill table entry is required to generate the pixels on that scanline following each edge.

The pixel generation module 1340 is pre-loaded with an aggregate fill table 1380 from the instruction job. The pixel generation module 1340, upon receiving a message from the edge behaviour table decoder module 1330, is responsible for retrieving the data in the appropriate aggregate fill table entry, and using the data therein to generate a colour for inclusion in the message for forwarding onto the pixel output module 1350, which is subsequently passed to the printer engine 695.

Fig. 14 shows a schematic flow diagram of a method 1400, performed by the pixel rendering apparatus 680, of rendering a page described by the edges, aggregate fill table and edge behaviour tables created by the controlling program 640. The method 1400 starts at step 1402 where the edge tracking module 1320 (Fig. 13) initialises the active edge list 1370 and the hidden edge list to be null-terminated empty lists, and sets the current scanline to the first scanline on the page.

688277 -57- O The edge tracking module 1320 then determines in step 1404 whether the current U scanline is beyond the end of the page. If it is determined that the current scanline is in fact beyond the edge of the page, then the method 1400 terminates at step 1405.

Alternatively, if it is determined that the current scanline has not yet reached the edge of 00 5 the page then, in step 1407, the edge tracking module 1320 sets the last active fill to the aggregate fill corresponding to the background colour (typically white).

Following step 1407, in step 1409 the edge tracking module 1320 determines whether the hidden edge list is empty. If the hidden edge list is empty then the edge tracking module 1320 in step 1430 inserts any new edges (ie. those starting on the current scanline) into the active edge list 1370. The edge tracking module 1320 then determines whether the active edge list 1370 is empty in step 1432. If the active edge list 1370 is empty then, in step 1436, the pixel generation module 1340 generates pixels for the entire current scanline using the last active fill. The current scanline is incremented in step 1437 before execution in method 1400 returns to step 1404.

Referring again to step 1432, if the active edge list 1370 is determined not to be empty, then the edge tracking module 1320 at step 1434 loads the first edge in the active edge list 1370 into a variable this_edge. Execution proceeds to step 1439 where the pixel generation module 1340 renders pixels from the left edge of the page to the x-position of the edge loaded into the variable this_edge using the last active fill. Step 1440 follows where the edge tracking module 1320 determines whether the value of the variable thisedge is NULL, ie. whether the end of the active edge list 1370 has been reached. If it is determined in step 1440 that the value of the variable this_edge is not NULL, the edge behaviour table decoding module 1330 in step 1442 then uses the current scanline to locate the active entry in the this_edge's edge behaviour table in the edge behaviour tables 1375 by comparing the current scanline with the lifetime field of each entry. Once 688277 -58- O the active entry has been located, the edge behaviour table decoding module 1330 U retrieves the "hidden" attribute of the active entry in step 1444. The method 1400 then proceeds to step 1446 where the edge behaviour table decoding module 1330 determines whether the "hidden" attribute is true, indicating that the edge loaded into the variable 00 5 thisedge is hidden on the current scanline. If the "hidden" attribute is determined to be true in step 1446, the edge behaviour table decoding module 1330 then determines in step 1477 whether the currently active entry in the edge's edge behaviour table has lifetime data equal to "for the remainder of the edge". If the current active entry in the edge's edge behaviour table does not have such a lifetime data entry, the edge tracking module 1320 then in step 1480 inserts the edge in the variable this_edge into the hidden edge list.

If it is determined in step 1477 that the current active entry in the edge's edge behaviour table does have a lifetime data entry equal to "for the remainder of the edge", or following step 1480, the edge tracking module 1320 in step 1482 removes the variable thisedge from the active edge list 1370.

If it was determined in step 1446 that the edge in the variable this_edge is not hidden, then the edge behaviour table decoding module 1330 in step 1448 retrieves the "aggregate fill index" attribute of the active entry for variable this_edge from the edge's edge behaviour table, and in step 1450 sets the last active fill to this value.

Following either step 1450 or step 1482, the pixel generation module 1340 in step 1484 determines whether the edge in the variable this_edge is the last non-NULL edge in the active edge list 1370, ie. whether the next edge in the active edge list 1370 is NULL. If it is determined that the next edge in the active edge list 1370 is not NULL, the pixel generation module 1340 in step 1486 renders pixels for the span between the xposition of the edge in the variable thisedge and the x-position of the next edge in the active edge list 1370 using the entry in the aggregate fill table 1380 indicated by the last 688277 -59- O active fill. Alternatively, if it is determined in step 1484 that the next edge in the active U edge list 1370 is in fact NULL, then the pixel generation module 1340 in step 1488 renders pixels for the span between the x-position of the edge in the variable this_edge and the right hand edge of the page using the entry in the aggregate fill table 1380 00 5 indicated by the last active fill.

The amount of compositing required at steps 1486 and 1488 depends on the (Ni operation performed by the primitives processor 640b when the primitives processor 640b Screated the indicated aggregate fill table entry in step 1590 (Fig. 15c). If the primitives processor 640b performed the compositing, the required fill is simply copied from the indicated aggregate fill table entry by the pixel generation module 1340. Otherwise, the pixel generation module 1340 performs the compositing from the fills and operations contained in the indicated aggregate fill table entry.

Following either step 1486 or 1488, in step 1320 the edge tracking module 1320 sets the variable this_edge to the next edge in the active edge list 1370, and execution returns to step 1440.

If it is determined in step 1440 that the value of the variable this_edge is NULL, indicating the end of the active edge list 1370 has been reached, then method 1400 proceeds to step 1455 where the edge tracking module 1320 sets the variable this_edge to the first entry in the active edge list 1370. In step 1457 that follows the edge tracking module 1320 determines whether the value of the variable this_edge is NULL, ie. whether the end of the active edge list 1370 has been reached. If it is determined that the end of the active edge list 1370 has not been reached, the edge tracking module 1320 then in step 1459 determines whether the edge in the variable this_edge terminates on the current scanline. If it is determined that the edge in the variable this_edge does terminate on the current scanline, then in step 1470 the edge tracking module 1320 removes thisedge 688277 O from the active edge list 1370. In the case where it is determined in step 1459 that the U edge in the variable this_edge does not terminate on the current scanline, the edge Stracking module 1320 updates the x-position of the variable thisedge for the next scanline in step 1463.

00 5 Following either step 1463 or step 1470, in step 1472 the edge tracking module 1320 sets the variable this_edge to the next entry in the active edge list 1370, and the C€3 method 1400 returns control to step 1457.

SIf it is determined in step 1457 that the value of the variable this edge is NULL, indicating that the end of the active edge list 1370 has been reached, the edge tracking module 1320 in step 1466 sorts the active edge list based on the x-position of each active edge on the next scanline. Execution of the method 1400 then returns to step 1404 via step 1437.

Referring again to step 1409, if the edge tracking module 1320 determines that the hidden edge list is not empty, then in step 1412 the edge tracking module 1320 sets the variable thisedge to the first edge in the hidden edge list. In the following step 1415, the edge tracking module 1320 determines whether the value of variable this_edge is NULL, indicating that the end of the hidden edge list has been reached. If the end of the hidden edge list has been reached, then the method 1400 continues to step 1430. If it is determined in step 1415 that the value of variable this_edge is not NULL, that is the end of the hidden edge list has not been reached, the edge behaviour table decoding module 1330 in step 1417 uses the current scanline to locate the active entry in the this_edge's edge behaviour table by comparing the current scanline with the lifetime field of each entry. Once the active entry has been located, the edge behaviour table decoding module 1330 retrieves the "hidden" attribute of the active entry in step 1420.

688277 -61- O Execution proceeds to step 1422 where the edge behaviour table decoding Smodule 1330 determines whether the "hidden" attribute is true, indicating that the edge in Sthe variable this_edge is still hidden on the current scanline. If the edge in the variable thisedge is no longer hidden, the edge tracking module 1320 in step 1424 calculates the 00 5 x-position on the current scanline of the edge in the variable this_edge. Also, the edge tracking module 1320 in step 1426 inserts the edge in the variable this_edge into the (Ni Ci active edge list 1370 based on its calculated x-position, and removes the edge in the variable this edge from the hidden edge list. If it is determined in step 1422 that the edge (-i in the variable this_edge is still hidden, or following step 1426, the edge behaviour table decoding module 1330 then sets the variable thisedge to the next entry in the hidden edge list before the method 1400 returns to step 1415.

The effect of steps 1477 to 1482 and 1417 to 1426 is that an edge that starts as, or becomes, hidden is discarded unless it is known to become un-hidden at a later scanline. In this case, the edge is added to the hidden edge list, where its x-position is not tracked between scanlines and that edge cannot affect the last active fill variable. Once the edge becomes un-hidden the edge rejoins the active edge list in the correct location according to its newly updated x-position. This saves both tracking and sorting computation on the active edge list 1370 by restricting these operations to non-hidden edges on any scanline.

The operation of the pixel rendering apparatus 680 is further illustrated by way of example with reference to page 1100 shown in Fig. 11, and in particular the rendering of scanline 1180. Reference is also made to tables 23 to 27 wherein the aggregate fill table created for objects 1110 and 1120 in Fig. 11 and the edge behaviour tables of edges 1130, 1140, 1150 and 1160 are shown.

688277 -62- O The first edge encountered on scanline 1180 is edge 1130. The pixel rendering U apparatus 680 generates white pixels for scanline 1180 from the left hand edge of the page until the x-position of edge 1130 on scanline 1180.

The pixel rendering apparatus 680 then determines the length of the span 00 5 between edge 1130 and the next edge on scanline 1180, which is edge 1150. The aggregate fill table entry that has to be used to generate the pixel colours for the span (Ni between edge 1130 and edge 1150 is determined by finding the currently active edge Sbehaviour table entry for edge 1130 on scanline 1180.

Given that the lifetime entries for the edge behaviour table for edge 1130 are relative to the start of edge 1130, the edge behaviour table entry that is active for scanline 1180 is calculated to be the first entry in Table The aggregate fill table index corresponding to edge 1130 in its edge behaviour table is Index 1 This aggregate fill table entry is therefore used to generate the pixels for the span between edge 1130 and edge 1150. Those pixels are therefore rendered in a flat light grey colour.

The pixel rendering apparatus 680 next determines the length of the span between edge 1150 and the next edge on scanline 1180, edge 1140. The aggregate fill table entry that is used to generate the pixel colours for this span is determined by finding the currently active edge behaviour table entry for edge 1150 on scanline 1180.

Given that the lifetime entries for the edge behaviour table for edge 1150 are relative to the start of edge 1150, the edge behaviour table entry that is active for scanline 1180 is calculated to be the first entry in Table 27.

The aggregate fill table index for edge 1150 in edge 1150's edge behaviour table is Index 3 This aggregate fill table entry is therefore used to generate the pixels for 688277 -63 O the span between edge 1150 and edge 1140, which specifies that the pixels of that span U are to be a flat grey colour.

SThe pixel rendering apparatus then determines the length of the span between edge 1140 and the next edge on scanline 1180, edge 1160. The aggregate fill table entry 00 5 that has to be used to generate the pixel colours for this span is determined by finding the currently active edge behaviour table entry for edge 1140 on scanline 1180. The edge (Ni N behaviour table entry that is active for scanline 1180 is calculated to be the second entry Sin Table 26.

The aggregate fill table index for edge 1140 in edge 1140's edge behaviour table is Index 2 This aggregate fill table entry is therefore used to generate the pixels in a flat dark grey colour for the span between edge 1140 and edge 1160.

Finally the pixel rendering apparatus 680 determines the length of the span between edge 1160 and the right hand side of the page, since there are no more edges encountered following edge 1160 on scanline 1180. The aggregate fill table entry that must be used to generate the pixel colours for this span is determined by finding the currently active edge behaviour table entry for edge 1160 on scanline 1180.

Given that the edge behaviour table for edge 1160 has only one entry the edge behaviour table entry that is active for scanline 1180 is calculated to be the first entry in Table 28.

The aggregate fill index for edge 1160 in edge 1160's edge behaviour table is Index 0 This aggregate fill table entry is therefore used to generate the pixels in a flat white colour for the span between edge 1160 and the right hand side of the page 1100.

Next the rendering by the pixel rendering apparatus 680 of objects with a hidden part of an edge is illustrated by way of example with reference to Fig. 10, and in particular the rendering of scanline 1085. Reference is also made to tables 17 to 21 688277 64 O wherein the aggregate fill table created for objects 1010 and 1020 in Fig. 10 and the edge U behaviour tables of edges 1030, 1040, 1050 and 1060 are shown.

SThe first edge encountered on scanline 1085 is edge 1030. The pixel rendering apparatus 680 generates white pixels for scanline 1085 from the left hand edge of the 00 5 page until the x-position of edge 1030 on scanline 1085.

The pixel rendering apparatus determines the length of the span between edge (Ni N 1030 and the next edge on scanline 1085, edge 1050. The aggregate fill table entry that has to be used to generate the pixel colours for this span is determined by finding the currently active edge behaviour table entry for edge 1030 on scanline 1085. The edge behaviour table entry that is active for scanline 1085 is calculated to be the first (and only) entry in Table 13.

The aggregate fill table index corresponding to edge 1030 in its edge behaviour table is Index 1 This aggregate fill table entry is therefore used to generate the pixels for the span between edge 1030 and the next edge on scanline 1085, edge 1050.

The pixel rendering apparatus 680 determines the length of the span between edge 1050 and the next edge on scanline 1085, edge 1040. The aggregate fill table entry that has to be used to generate the pixel colours for this span is determined by finding the currently active edge behaviour table entry for edge 1050 on scanline 1085.

Given that the lifetime entries for the edge behaviour table for edge 1050 are relative to the start of edge 1050, the edge behaviour table entry that is active for scanline 1085 is calculated to be the first entry in Table The hidden flag attribute for edge 1050 in edge 1050's edge behaviour table's first entry is TRUE and hence an optimisation is possible in that there is no need to read the aggregate fill table index in this table. The same aggregate fill table entry (Fa) that was used on the previous span (between edge 1030 and edge 1050) is therefore used to 688277 O generate the pixels for the span between edge 1050 and the next edge on scanline 1085, O edge 1040.

The pixel rendering apparatus 680 next determines the length of the span between edge 1040 and the next edge on scanline 1085, edge 1060. The aggregate fill 00 5 table entry used to generate the pixel colours for this span is determined by finding the r- currently active edge behaviour table entry for edge 1040 on scanline 1085. The edge MNi N behaviour table entry that is active for scanline 1085 is calculated to be the second entry Sin Table 14.

The aggregate fill table index for edge 1040 in edge 1040's edge behaviour table is Index 2 This aggregate fill table entry is therefore used to generate the pixels for the span between edge 1040 and the next edge on scanline 1085, edge 1060.

Finally the pixel rendering apparatus 680 determines the length of the span between edge 1060 and the right hand side of the page, since there are no more edges encountered following edge 1060 on scanline 1085. The aggregate fill table entry that has to be used to generate the pixel colours for this span is determined by finding the currently active edge behaviour table entry for edge 1060 on scanline 1085.

Given that the edge behaviour table for edge 1060 has only one entry the edge behaviour table entry that is active for scanline 1085 is calculated to be the first entry in Table 16.

The aggregate fill index for edge 1060 in edge 1060's edge behaviour table is Index 0 This aggregate fill table entry is therefore used to generate the pixels for the span between edge 1060 and the right hand side of the page.

The two examples of the operation of the pixel rendering apparatus 680 use relatively simple pages. In many cases the edges, aggregate fill table and edge behaviour 688277 -66tables will be far more complex, with many entries. However the fundamental method O 1400 of rendering shown in Fig. 14 is valid for all cases.

SAlso, by describing the operation of the pixel rendering system 600 (Fig. 6) in detail, computer programs are also implicitly disclosed in that it would be apparent to the 00 5 person skilled in the art that the individual steps described herein are to be put into effect 0\ rby computer code. The computer programs are not intended to be limited to any particular control flow.

SSuch computer programs may be stored on any computer readable medium. The computer readable medium may include storage devices such as magnetic or optical disks, memory chips, or other storage devices suitable for interfacing with a processor.

The computer programs when loaded and executed on such processors results in the respective component parts of system 600 described herein.

It is also noted that 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.

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.

688277

Claims (11)

1. A representation of a page to be rendered, said page comprising one or more graphic objects, each graphic object being defined by two or more edges, said 00 5 representation comprising for at least one edge on said page: position data of one or more segments forming said edge; (Ni N at least two attributes, each said attribute defining pixel properties of pixels on a Sscanline in the rendering direction following said edge; and for each said attribute, data representing the scanlines over which said attribute is valid.

2. The representation according to claim 1 further comprising an ordered list of pixel properties and wherein each said attribute contains a pointer to an entry within said ordered list.

3. The representation according to claim 1 or 2 wherein each said attribute includes a flag indicating that said pixel properties of said span of pixels following said edge are substantially identical to the pixel properties of the span of pixels preceding said edge in the rendering direction.

4. The representation according to any one of claims 1 to 3 wherein said pixel properties are derived from compositing two or more of said graphic objects. 688277 -68- A method of rendering a page, said page comprising one or more graphic objects, o each graphic object being defined by two or more edges, said method comprising the steps of: receiving a representation of said page, said representation comprising for at 00 5 least one edge on said page: position data of one or more segments forming said edge; N at least two attributes, each said attribute defining pixel properties of pixels Son a scanline in the rendering direction following said edge; and (,i for each said attribute, data representing the scanlines over which said attribute is valid; determining from said position data the pixel locations at which said segments of said edges cross a current scanline; associating at least one said attribute with each span of pixels, each span of pixels being defined by two of said pixel locations; and rendering said spans of pixels on said current scanline using said at least one associated attribute.

6. The method according to claim 5, wherein said associating step uses said data representing the scanlines over which each said attribute is valid.

7. The method according to claim 5, wherein said representation further comprises an ordered list of pixel properties and wherein said attribute contains a pointer to an entry within said ordered list. 688277 -69- S8. The method according to claim 7, wherein said rendering step comprises the su- U steps of: obtaining said entry using said pointer, and rendering each said span using the pixel properties of said entry. 00

9. The method according to claim 5 or 7, wherein each said attribute includes a flag (Ni indicating that said pixel properties of said span of pixels following said edge is Ssubstantially identical to the pixel properties of the span of pixels preceding said edge in the rendering direction. The method according to claim 7, wherein said rendering step comprises obtaining said pixel properties from the span of pixels preceding said edge in the rendering direction if said flag is set. 11 A computer program for rendering a page, said page comprising one or more graphic objects, each graphic object being defined by two or more edges, said program comprising: code for receiving a representation of said page, said representation comprising for at least one edge on said page: position data of one or more segments forming said edge; at least two attributes, each said attribute defining pixel properties of pixels on a scanline in the rendering direction following said edge; and for each said attribute, data representing the scanlines over which said attribute is valid: 688277 0 code for determining from said position data the pixel locations at which said Ssegments of said edges cross a current scanline; Scode for associating at least one said attribute with each span of pixels, each span of pixels being defined by two of said pixel locations; and 00 5 code for rendering said spans of pixels on said current scanline using said at least one associated attribute. C€3

12. A renderer for rendering a page, said page comprising one or more graphic objects, each graphic object being defined by two or more edges, said method comprising: means for receiving a representation of said page, said representation comprising for at least one edge on said page: position data of one or more segments forming said edge; at least two attributes, each said attribute defining pixel properties of pixels on a scanline in the rendering direction following said edge; and for each said attribute, data representing the scanlines over which said attribute is valid; means for determining from said position data the pixel locations at which said segments of said edges cross a current scanline; means for associating at least one said attribute with each span of pixels, each span of pixels being defined by two of said pixel locations; and means for rendering said spans of pixels on said current scanline using said at least one associated attribute.

13. A method of forming a representation of a page to be rendered over a plurality of scanlines, said page comprising one or more graphic objects, each graphic object being 688277 -71 defined by two or more edges, said method comprising, for at least one edge on said page, the steps of storing position data of one or more segments forming said edge; determining and storing at least two attributes, each said attribute defining pixel 00 5 properties of pixels following said edge in the rendering direction; and determining and storing data for each said attribute, representing the scanlines C over which said attribute is valid.

14. A representation of a page to be rendered, said representation being substantially as described herein with reference to Figs. 6 to 15d of the accompanying drawings. A method of rendering a page substantially as described herein with reference to Figs. 6 to 15d of the accompanying drawings.

16. A renderer substantially as described herein with reference to Figs. 6 to 15d of the accompanying drawings. DATED this Fourteenth Day of December, 2004 CANON KABUSHIKI KAISHA Patent Attorneys for the Applicant SPRUSON FERGUSON 688277