AU2003204832B2 - Rendering Graphic Object Based Images - Google Patents

Description

S&F Ref: 636114

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 30-2, Shimomaruko 3-chome, Ohta-ku Tokyo 146 Japan Colin John Newell Spruson Ferguson St Martins Tower Level 31 Market Street Sydney NSW 2000 (CCN 3710000177) Rendering Graphic Object Based Images ASSOCIATED PROVISIONAL APPLICATION DETAILS [33] Country [31] Applic. No(s) AU PS3102 [32] Application Date 21 Jun 2002 The following statement is a full description of this invention, including the best method of performing it known to me/us:- 5815c RENDERING GRAPHIC OBJECT BASED IMAGES Field of the Invention The present invention relates generally to rendering graphic object based images.

In particular, the present invention relates to generating an instruction job'for instructing a rendering apparatus to render a plurality of graphical objects.

Background When a computer application provides data to a device for printing and/or display, an intermediate description of the page is often given to the device driver software in a page description language, such as PostScriptTM or PCL, which provide descriptions of the objects to be rendered onto the page, rather than a raster image to be printed.

Equivalently, a set of descriptions of graphics objects may be provided in function calls to a graphics interface, such as the GDI in the Microsoft WindowsTM operating system, or the X- 11 in the Unix T M operating system. The page is typically rendered for printing and/or display by an object-based graphics system (or Raster Image Processor).

Most of these object based graphics systems utilize a large area of memory, known to the art as a frame store or a page buffer, to hold a pixel-based image of the page or screen for subsequent printing and/or display. Typically, the outlines of the graphic objects are calculated, filled and written into the frame store. For two-dimensional graphics, objects that appear in front of other objects are simply written into the frame store after the background objects, thereby replacing the background on a pixel by pixel basis. This is commonly known to the art as "Painter's algorithm". Objects are considered in priority order, from the rearmost object to the foremost object, and typically, each object is rasterized in scanline order and pixels are written to the framestore in sequential runs along each scanline. Some graphics interfaces allow a logical or arithmetic operation to 636114.DOC be specified, to be performed between one or more graphics objects and the already rendered pixels in the frame buffer. In these cases the principle remains the same: objects (or groups of objects) are rasterized in scanline order, and the result of the specified operation is calculated and written to the framestore in sequential runs along each scanline.

There are essentially two problems with this technique. The first is that the technique requires fast random access to all of the pixels in the framestore. This is because each new object could affect any pixel in the frame store. For this reason, the frame store is normally kept in semiconductor random access memory (RAM). For high-resolution colour printers the amount of RAM required is very large, typically in excess of 100 Mbytes, which is relatively costly and difficult to run at high speed. The second problem is that many pixels, which are painted (rendered), are over-painted (re-rendered) by later objects. Painting these pixels with the earlier objects is a waste of time.

One method for overcoming the large frame-store problem is the use of "banding".

When banding is used, only part of the framestore exists in memory at any one time. All of the objects to be drawn are retained in a "display list", which is an internal representation of the information required to draw the objects on the page. The display list is considered in object order as above, and only those pixel operations which fall within the fraction of the page which is held in the band are actually performed. After all objects in the display list have been drawn, the band is sent to the printer (or to intermediate storage) and the process is repeated for the next band of the page. There are some penalties with this technique, however. For example, the objects being drawn must be reconsidered many times, once for each band. As the number of bands increases, so 636114.DOC -3does the repetitious examination of the objects requiring rendering. Also, the technique of banding does not solve the problem of the cost of over-painting.

Some other graphic systems consider the image in scan line order. Again, all of the objects on the page are retained in a display list. On each scanline the objects which intersect that scanline are then considered in priority order and for each object, spans of pixels between the intersection points of the object edges with the scanline are filled in a line store. This technique overcomes the large frame store problem, but however still suffers from the over-painting problem.

Other graphic systems utilize pixel-sequential rendering to overcome both the large framestore problem and the over-painting problem. In these systems, each pixel is generated in raster order. Again, all objects to be drawn are retained in a display list. On each scan line, the edges of objects, which intersect that scanline, are held in increasing order of their intersection with the scan line. These points of intersection, or edge crossings, are considered in turn, and used to toggle an array of fields that indicate the activity of the objects in the display list. There is one activity field for each object painting operation that is of interest on the scan line. There is also a field to indicate operations that do not require previously generated data. Between each pair of edges considered, the colour data for each pixel, which lies between the first edge and the second edge, is generated by using a priority encoder on the activity flags to determine which operations are required to generate the colour, and performing only those operations for the span of pixels between the two edges. In preparation for the next scanline, the coordinate of intersection of each edge is updated in accordance with the nature of each edge, and the edges are sorted into increasing order of intersection with that scanline. Any new edges are also merged into the list of edges.

636114.DOC -4- Graphic systems which use pixel-sequential rendering have significant advantages in that there is no frame store or line store, no unnecessary over-painting, and the object priorities are dealt with in constant order time by the priority encoder, rather than in order N time, where N is the number of priorities.

Australian Patent Publication No. AU-B-47508/99 (744091), and its corresponding United States Patent Application No. 09/394530, discloses such a pixel sequential rendering system. The system comprises a pixel sequential rendering engine used in conjunction with driver software that receives graphical objects from an application program, a host computer system, and a downstream printer device. This system is capable of rendering graphical shapes, images and text in colour. The system operates by building and processing graphical objects (defined by edges, fills, levels and colour operations), and then producing colour output one scanline at a time. For each scanline the engine processes each pixel in turn, considering the graphical objects that affect that pixel, to determine the output for the pixel. The engine maintains a table of active fills (known as the fill table) and a table of active levels (known as the level table), which are used in the determination of those objects which make an active contribution to the current pixel and their associated fills. However, complex printing jobs may have many objects and as such require more levels and fills than can be accommodated in the available table sizes in host memory. When this happens, the driver software must produce a job to render a subset of the full job, and instruct the rendering engine to save the colour data output in memory. The driver software then produces another job to render the next part of the full job, with the engine using the previously stored data as a background image. Using this technique, complex jobs can be rendered. However this layering process is slow and inefficient.

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

According to one aspect of the invention, there is provided a method of generating an instruction job for instructing a rendering apparatus to render a plurality of graphical objects, the method comprising the steps of: building a plurality of fill and level tables, wherein each said fill table and level table comprises a plurality of entries, where each said entry of a fill table defines a fill of a corresponding said graphical object and each said entry of a level table defines a level of a corresponding said graphical object; and adding instructions to the instruction job, wherein said instructions comprise a plurality of register instructions, each register instruction of a first set of said plurality of register instructions being adapted to set a first register of the rendering apparatus for referencing a corresponding said fill table and each register instruction of a second set of said plurality of register instructions being adapted to set a second register of the rendering apparatus for referencing a corresponding said level table.

According to another aspect of the invention, there is provided apparatus for generating an instruction job for instructing a rendering apparatus to render a plurality of graphical objects, the apparatus comprising: means for building a plurality of fill and level tables, wherein each said fill table and level table comprises a plurality of entries, where each said entry of a fill table defines a fill of a corresponding said graphical object and each said entry of a level table defines a level of a corresponding said graphical object; and means for adding instructions to the instruction job, wherein said instructions comprise a plurality of register instructions, each register instruction of a first set of said plurality of register instructions being adapted to set a first register of the rendering 636114.DOC -6apparatus for referencing a corresponding said fill table and each register instruction of a second set of said plurality of register instructions being adapted to set a second register of the rendering apparatus for referencing a corresponding said level table.

According to another aspect of the invention, there is provided a computer program for generating an instruction job for instructing a rendering apparatus to render a plurality of graphical objects, the computer program comprising: code for building a plurality of fill and level tables, wherein each said fill table and level table comprises a plurality of entries, where each said entry of a fill table defines a fill of a corresponding said graphical object and each said entry of a level table defines a level of a corresponding said graphical object; and code for adding instructions to the instruction job, wherein said instructions comprise a plurality of register instructions, each register instruction of a first set of said plurality of register instructions being adapted to set a first register of the rendering apparatus for referencing a corresponding said fill table and each register instruction of a second set of said plurality of register instructions being adapted to set a second register of the rendering apparatus for referencing a corresponding said level table.

According to still another aspect of the invention, there is provided a system for rendering graphic objects, wherein the system comprises: a computer program for generating an instruction job for instructing a rendering apparatus to render a plurality of graphical objects, the computer program comprising: code for building a plurality of fill and level tables, wherein each said fill table and level table each comprise a plurality of entries, where each said entry of a fill table defines a fill of a corresponding said graphical object and each said entry of a level table defines a level of a corresponding said graphical object; code for adding instructions to the instruction job, wherein said instructions comprise a plurality of register instructions, each register instruction of a first set of said 636114.DOC -7plurality of register instructions being adapted to set a first register of a rendering apparatus for referencing a corresponding said fill table and each register instruction of a second set of said plurality of register instructions being adapted to set a second register of a rendering apparatus for referencing a corresponding said level table; and code for sending said instruction job to the rendering apparatus; and rendering apparatus for rendering said graphical objects in response to receiving said instruction job, wherein said apparatus comprises: memory for storing said fill and level tables; and rendering engine for generating colour output, for each pixel in turn, in response to instructions in said instruction job; wherein said rendering engine comprises: a first register and a second register for referencing a said fill table and a said level table respectively in said memory; and a controller for interpreting said register instructions in said instruction job and setting said registers to an address of said fill and level tables in said memory.

Brief Description of the Drawings One or more preferred embodiments of the present invention will now be described with reference to the drawings, in which: Fig. 1 shows an example of two graphical objects on a page for illustrating how the preferred rendering system works; Fig. 2 shows another simple example for illustrating how the preferred rendering system works; Fig. 3 shows another example for illustrating how the preferred rendering system works; Figs. 4A, 4B and 4C show a flow chart of a method for generating an instruction job containing a set of instructions for forwarding to the rendering engine; 636114.DOC -8- Fig. 5 shows a flowchart of the buildfill_table sub-process of Figs. 4A to 4C for building a new fill table; Fig. 6 shows a flowchart of the build_level_table sub-process of Figs. 4A to 4C for building a new level table; Fig. 7 shows a flowchart of the insert_level sub-process of Figs. 4A to 4C, and 6 for inserting an object level into a new level table; Fig. 8 illustrates schematically the preferred pixel sequential rendering system for rendering of computer graphic object images, and Fig. 9 is a flowchart of the splitobjects sub-process called from Figs. 4B and C.

Detailed Description including Best Mode 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.

1.0. Overview of Pixel Sequential Rendering System Fig. 8 illustrates schematically a pixel sequential rendering system for rendering computer graphic object images. The rendering system 800 comprises a client personal computer 810 having a client processor 820 for executing a client software application 830, such as a word processor or graphical software application. In the system 800, the application 830 creates page-based documents where each page contains objects such as text, lines, fill regions, and image data. The software application 830 preferably sends a page for printing in the form of an application job. This application job is forwarded via a GDI layer to the preferred controlling program 840, which generates an instruction job comprising graphic object-based descriptions together with instructions. This instruction 636114.DOC job is then forwarded via the network 850 to the host processor 870 of the host printing system 860 for printing. The network may be a typical network containing multiple client personal computers, or may be a simple connection between a single personal computer and host printing system 860. In a still further variation the controlling program instead of being executed on the client personal computer may be executed on the host printing system 860, and where the client personal computer forwards the application job to the controlling program via the network 850.

The host printing system 860 comprises a host processor 870, memory 890, a pixel sequential rendering engine 880, and a printer engine 895 coupled via a bus 875. The rendering engine 880 is preferably in the form of an ASIC card coupled via the bus 875 to the host processor 870, and the printer engine 895. The preferred controlling program 840 (preferably in the form of a driver on a WindowsTM or MacintoshTM operating system) receives graphical objects from an application program 830, and constructs an instruction job understood by the rendering engine 880. Preferably, the client application 830 provides data to the preferred controlling program, 840 for printing, by calling subroutines in the GDI layer, which provide descriptions of the objects to be rendered onto the page, rather than a raster image to be printed.

The preferred controlling program 840 is preferably a driver on a WindowsTM or MacintoshTM operating system. The program 840 receives graphical objects from an application program 830 that wishes to print a job using the rendering engine 880. The program 840 builds a job containing a set of instructions for forwarding to the rendering engine 880, together with data representing graphical objects. In the present context ajob represents one page of output.

636114.DOC When the preferred controlling program 840 has prepared a complete instruction job, the job is transferred via the network to the host processor 870, which controls the rendering engine 880. A host controlling program executing on the host processor 870 is responsible for receiving jobs from the preferred controlling program 840, providing memory 890 for the rendering engine 880, and instructing the rendering engine 880 to start rendering the job. The host controlling program on the host processor 870 tells the rendering engine 880 the location in memory 890 of the job to be rendered, and instructs the engine 880 to start rendering, whereupon the engine 880 interprets the instructions and data in the job, and renders the page, without further involvement from the host processor 870. The output of the engine 880 is colour pixel data, which can be used by the output stage of the printer 895.

The rendering engine 880 employs a pixel-based sequential rendering method. When the engine 880 renders the job, for each pixel, the contributing objects are determined and the resulting colour is calculated. Redundant operations are eliminated because only contributing objects are used. The contributing objects remain the same between the edges of objects, so this determination is only made on an edge-by-edge basis.

Overview of Pixel Sequential Rendering Engine A brief overview of the pixel sequential rendering engine 880 is now discussed.

Preferably, the rendering engine 880 is the form of a ASIC chip, however the rendering engine may also be implemented in software. Preferably, the pixel sequential rendering engine 880 comprises an instruction execution module; an edge tracking module; a priority determination module; a pixel generation module; a pixel compositing module; and a pixel output module arranged in a pipeline. For each scanline the engine 880 processes each pixel in turn, considering the graphical objects that affect that pixel, to 636114.DOC 11 determine the output for the pixel. The instruction execution module reads and processes instructions from the instruction job and formats the instructions into messages that are transferred to the other modules within the pipeline. The edge tracking module is responsible for determining the edges of those graphical objects of the instruction job that intersect the currently scanned pixel and passes this information onto the priority determination module. The priority determination module is pre-loaded with a level table from the instruction job, which level table contains an entry for each graphical object 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 determination module is responsible for determining those objects, so called active objects, that make a visual contribution to the currently scanned pixel and passes that information in the form of messages onto the pixel generation module. These messages each contain an index that references the fill of a corresponding active object in a fill table. The pixel generation module is pre-loaded with the fill table from the instruction job, which fill table contains an entry for each graphical object consisting of the graphical object's fill and other data. The pixel generation module is responsible upon receiving a message from the priority determination module of referencing the index into the fill table, and using the data therein to generate a colour field for inclusion in the message for forwarding onto the pixel compositing module. The pixel compositing module 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 messages.

The final output colour of the pixel is passed onto the pixel output module, which is subsequently passed to the printer/display device.

636114.DOC 12- Any known pixel sequential rendering engine that operates by building and processing graphical objects (defined by edges, fills, levels and colour operations), such as that described above would with a number of modifications be suitable for use in the aforementioned preferred pixel sequential rendering system 800. These modifications are described below in more detail.

'The present invention particularly relates to the interrelationship between the preferred controlling program 840 and the preferred pixel sequential rendering engine 880. The preferred controlling program 840 together with the preferred rendering engine 880 makes it possible for the system 800 to handle very complex printing jobs. In addition, the present invention also relates to the rendering engine including these modifications per se, and the preferred controlling program per se. In order to understand the operation of the preferred rendering system 800, a more detailed description of the operation of the preferred rendering engine 880 follows in so far as it interrelates with the preferred controlling program 840.

2.1 Pixel Sequential Rendering Engine 2.1.1 Graphical Objects The graphical objects that are passed by the preferred controlling program to the rendering engine 880 for processing are defined in terms of: edges which describe the geometric shape of the object 0 a fill which describes the colour, the opacity, the colour blend and/or the image to be painted within the shape of the object level which describes whether the object should be painted above or behind other objects, and how colour from the object should be combined with objects behind this object, if the opacity of the object is not 100%.

636114.DOC 13- These are described in more detail below: 2.1.2 Edges Edges are used to describe the boundaries of an object. Each edge is a sequence of straight line segments in a monotonic increasing Y sequence. Edges can be used to approximate non-straight line boundaries by providing a sufficient number of sufficiently short straight line segments. Edges can also be used to describe text objects by treating each text character as a geometric shape whose boundaries are described by edges made up of straight line segments. Edges have a direction: up or down. (See Example 1, described below.) 2.1.3 Fills A fill is a description of the colour, pattern and/or image to be painted within the boundaries of an object. A fill can be a flat fill representing a single colour, a blend representing a linearly varying colour, an image or a tiled (ie. repeated) image. In each case the supplied fill is to be applied over the extent of the object. (See Example 1 described below) 2.1.4 Levels Each object to be rendered has a Z-order attribute. This attribute determines which objects appear on top of or beneath other objects. Each Z-order value corresponds to a level. Each edge has a level, which the edge activates.

Each level has a fill rule, which can 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 engine processes a scanline working across the page, when a downwards heading edge is crossed, the level's fill-count associated with the edge is incremented.

When an upwards heading edge is crossed, the level's fill-count associated with the edge 636114.DOC -14is 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 a odd-even fill rule, then the level is active if its associated fill count is odd.

In addition level entries have information describing the colour operation for the level, whether the level is opaque or partly or fully transparent, and how to combine colour for lower levels (if the level is not opaque). The colour operation specifies the method to combine colour from lower levels if the level is not opaque.

Each level has a NEEDBELOW flag. This is set to FALSE if no levels beneath this level in Z-order contribute to pixel output. If this flag is set to FALSE for a level, then during pixel output the engine does not need to consider any levels beneath this level.

Thus an object's extent is described by a set of edges. Each edge has a level, which may be activated or deactivated when the edge is crossed during rendering, and each level has a fill that describes the colour contribution of the object. The top most active level determines the colour output by the engine, but lower active levels may also contribute.

(See Example 1 described below) 2.1.5 Fill Table The rendering engine maintains a table of fill entries. The preferred controlling program builds the fill table as part of the job. For simple jobs there will be only one fill table used throughout the job. When the preferred controlling program has finished building the job, the built fill table will be placed in the job, and when the job is transferred to the engine's host system, the fill table will be placed in memory as part of the job. Fills are referenced by their index in the fill table.

2.1.6 Level Table 636114.DOC 15 The rendering engine maintains a table of level entries. The preferred controlling program builds the level tables as part of the job. For simple jobs there will be only one level table used throughout the job. When the preferred controlling program has finished building the job, the level table will be placed in the job, and when the job is transferred to the engine's host system, the level table will be placed in memory as part of the job.

Levels are referenced by their index in the level table. The order of entries in the level table is important. Entries with a higher index are painted above (and usually obscure) entries with a lower index.

2.1.7 Edge List The rendering engine maintains a current list of edges, which apply to the current scanline. As the engine renders a scanline, the current list of edges is used to determine when levels are activated/deactivated. An edge can control one or more levels. An edge contains information to describe its position on subsequent scanlines, and its height (in scanlines) on the page, the engine uses this information to recalculate edges after each scanline, and to remove terminated edges.

2.1.8 Example 1 In the example shown in Fig. 1, there are two graphical objects: a triangle with a light grey flat fill, and a square with a dark grey flat fill. B is above, and partially obscures, A. (In the Fig. 1, B is shown as partially transparent only to show the extent of A.) The triangle is described by two edges: El is downwards heading, with two segments (S 1 and S2), and E2 is upwards heading with one segment The square is described by two edges: E3 is downwards heading with two segments (S4 and S5), and E4 is upwards heading with two segments (S6 and S7).

636114.DOC 16- For this instruction job two fill entries are needed and the fill table is as follows: Table 1 Fill Table The level table is as follows: Table 2 Level Table Index Fill Index Fill Rule Need Below 1 1 (Fb) Non-zero False 0 0 (Fa) Non-zero False Edges El (Segments S1 and S2) and E2 (Segment S3) control Level 0, and Edges E3 (Segments S4 and S5) and E4 (Segments S6 and S7) control Level 1.

To understand how the rendering engine will process this job, consider scanline 220.

When rendering this scanline, left of point p, no levels are active, and the colour output by the engine will be RGB=(255,255,255).

At point p (pixel 78), El is crossed and as the edge is downwards heading the fill count is incremented to 1 and level 0 is activated. From point p to point q, Level 0 is the only active level, and the colour defined by its fill (fill Fa) is output (light grey). At point q, E3 is crossed, and as the edge is downwards heading the fill count is incremented to 1 and Level 1 is activated. From point q to point r, the highest active level is Level 1 and, since 636114 -17- Level I's NEED_BELOW flag is False, Level 0 does not contribute to the output. The Scolour defined by Level 1 's fill (dark grey) is output. At point r, E2 is crossed, and, as the edge is an upwards heading edge its fill count is decremented to zero, and Level 0 is deactivated. From point r to point s, Level 1 's fill (dark grey) is output. At point s, E4 is 00 5 crossed, and, as the edge is an upwards heading edge its fill count is decremented to zero, and Level 1 is deactivated. No levels are now active, and for the rest of the scanline (Ni RGB=(255,255,255) will be output.

This example shows the basis on which the rendering engine works, and shows a simple example of a fill and a level table. In most jobs the fill and level tables will be far more complex, with many entries. In complex jobs the number of entries can be very large, necessitating methods to deal with such table sizes.

2.1.9 Recognition of Visible Graphic Objects If several objects are visible, that is if they make a visible contribution to the currently scanned pixel, then the colour values contributed by the visible objects are composited together in the pixel compositing module to obtain the final pixel colour. The graphics compositing operations are stored in the Level Table, in the order in which they are to appear in the stack expression for a pixel. Each level entry contains a stack operation and an index into the fill table where colour information is stored, together with its activation conditions. The pixel compositing module implements this stack expression to generate the final output colour of the currently scanned pixel.

A graphic object is separated into four types of data: the object's edges, which describe the object's boundaries (stored in the edge list) and control the activation of the level(s) used by an object; 636114 -18the object's activation conditions (stored in the Level Table), which are used to determine whether a pixel needs to use data from the level, viz whether it makes a visible contribution to the currently scanned pixel; the stack operation(s) (also stored in the Level Table) which is used to composite the object onto the page: if a compositing operation requires several stack operations, a level is required for each; and the object'sfill data (stored in the fill table), with which the object is to be filled.

For each pixel, the activation state of each level is checked and the activated levels are used to generate the colour data for the pixel. This is done using stack commands built up from the compositing operators and fill data from the active levels. Note that the operations that are associated with a particular object are only performed when the object is contributing; that is, when the object is active and is not obscured by another object.

2.1.10 Edges, Level Activation and Contribution The activation of a level is controlled by the edges for that level and by the activation conditions of the level (including the fill rule). As rendering passes along a scanline, the levels controlled by each edge change state when rendering reaches the edge's position.

The coordinate system used by the edge tracking system has its integer boundaries on pixel boundaries. Levels change state on the rounded X-position of their controlling edge.

A level is contributing if the level is the uppermost active level, or if all active levels above it have their NEEDBELOW flag set ie., each level with 'need below' will require the level directly beneath it and so on. When determining the pixel values, the renderer only considers the contributing levels.

636114.DOC -19- Before the engine renders a scanline the engine will load new edges which begin on that scanline into the current edge list. Any edges that terminate on the scanline will be removed from the current edge list, after the scanline is rendered.

2.1.11 Pixel Generation and Compositing The compositing operation is also stored in the Level Table. As rendering proceeds, levels are activated and deactivated according to the activation conditions associated with the objects that use them. The final colour value for a pixel is obtained by building up a stack machine with the fill colours and compositing operations from active levels. The stack operations are evaluated from the lowest visible level to the topmost visible level.

2.1.12 Operation of the Rendering Engine When the preferred controlling program has built a instruction job, the job is transferred to the host processor 870 of the rendering engine 880. The host processor 870 will initialise the rendering engine 880, supply the starting location of the job, and instruct the engine to render the job. The engine then proceeds to render the job with no further interaction from the preferred controlling program.

While rendering, the engine uses the data that is in the current edge list, the level activation table and the fill table to generate pixels.

the current edge list contains information describing the boundaries of graphics objects the level activation table contains information describing when a graphics object may contribute data to rendered pixels (ie. when the object becomes active), and the compositing operation to be used 636114.DOC Sthe fill table contains information describing how to determine the colour which an object contributes to thepixel, when the object is active.

The rendered output takes the form of pixels as either 24 bit colour and 8 bit opacity or 32 bit colour, according to the desired colour mode.

2.1.13 Restrictions on Tables The pixel sequential rendering engine is limited in its capability for handling large fill and level tables. Because of these memory allocation restrictions it is preferable to enforce a limit of 256Kbytes for tables created by the preferred controlling program.

There are other reasons for limiting the size of the tables, for example restrictions pertaining to hardware support.

This means that Fill Tables are limited to 64K slots of 4bytes of memory, where each flat fill requires one slot, each image fill requires 7 or 8 slots, and each linear blend fill requires 7 slots. Other than flat fills, each fill must start at a slot number divisible by 8.

(This means a limit of about 8K non-flat fills plus several thousand flat fills.) Also, this means that the Level Table is limited to a maximum size of 32768 levels, where each level requires 8 bytes of memory.

However, as mentioned previously in the background section, complex printing jobs may have many objects and as such require more levels and fills than can be accommodated in the available table sizes in host memory. When this happens, the prior art controlling program produces a job to render a subset of the full job, and instruct the rendering engine to save the colour data output in memory. The driver software (viz the controlling program) then produces another job to render the next part of the full job, with the engine using the previously stored data as a background image. Using this technique, complex jobs can be rendered. However this layering process is slow and inefficient.

636114.DOC -21- The present preferred controlling program provides a technique that is adapted to build and use multiple fill and level tables, so that complex jobs can be rendered without resort to layering.

2.1.14 Rendering Engine Instruction Set The instruction controller of the preferred rendering engine 880 implements a set of instructions to control the operation of the rendering engine. The instruction job built by the preferred controlling program and output to the rendering engine, consists of these instructions, plus data describing edges, images, fills etc. As mentioned above, any known pixel sequential rendering engine that operates by building and processing graphical objects (defined by edges, fills, levels and colour operations), such as that described above would with some modifications be suitable for use in the aforementioned pixel sequential rendering system. These modifications include the following or their equivalent instructions.

INST SET BUF The engine has a register to point to the fill table (FILLTABLEBASE register), and a register to point to the level table (LEVEL_TABLEBASE) in memory. These registers are initialized by the INSTSET_BUF instruction. The instruction has two arguments: the register, and the address to load into the register. The priority determination module and fill determination module of the rendering engine can then access the appropriate fill and level tables via the addresses stored in the fill register and level register.

INST LOAD FILL DATA Fill data can be set up in an initialized block of memory, and based by the FILL_TABLEBASE register using an INSTSETBUF instruction. The block of memory is set up in the preferred controlling program. Sometimes it is useful to load 636114.DOC -22individual fills directly into the fill table. This can be done with the INST_LOAD_FILL_DATA instruction, which takes three arguments: the index of the first entry to initialize, the data to place in the table, and the size of the data.

INST LOAD LEVEL DATA This instruction allows loading of data directly into one entry of the level table. The instruction supplies the index of the level and the data to place in that level.

INST END JOB This instruction signals the end of the job to the engine.

INST LOAD EDGES AND RENDER This instruction loads new edge data into the engine's edge list, and instructs the engine to proceed and render a number of scanlines.

A typical job generated by the preferred controlling program will preferably involve the following instructions: instructions to load values into the Level Table Base register and the Fill Table Base register. These instructions will point the registers at blocks of memory which have been set up as part of the job, by the preferred controlling program; one or more 'Load Edges and Render' instructions: each instruction will load data for zero or more edges, and then command the engine to render a certain number of scanlines using the loaded edges in conjunction with the data in the fill and level tables. It is possible for a Load Edges and Render instruction to provide no edges, which happens when there is a section of page with no active objects. The engine will effectively skip the specified number of scanlines; 636114 -23- (if the job contains multiple Fill and Level Tables, there will be more [INSTSETBUF instructions to rebase the Fill Table Base register and Level Table Base register; Sat the end of the job there will be a INSTEND-JOB instruction. This instruction 00 5 signals the end of the job, whereupon the engine will raise a signal to inform the i host system that the job is complete. The host system will then receive the next job from the preferred controlling program and the process restarts.

These instructions enable the following advantages over prior art rendering engines.

the fill table can be placed anywhere in the memory of the host system. The start of the fill table is addressed by a register known as the FILL_TABLE_BASE register, which is a 32 bit register addressing host memory. The engine executes an JNST_SETBUF instruction to set up the base register to point to the fill table Sthe fill table can be set up in the preferred controlling program by creating and initializing a block of memory which will be transferred to the host system as part of thejob the engine can activate another fill table simply by executing another INSTSETBUF instruction register to change the base register point to another area of memory the level table can be placed anywhere in the memory of the host system. The level table is addressed by the LEVEL_TABLE_BASE register. The engine executes an JNST_SETBUF instruction register to set up the base register to point to the level table Sthe level table can be set up in the preferred controlling program by creating and initialising a block of memory 636114 -24- (the engine can activate another level table simply by executing another SINSTSET BUF instruction register to change the base register to point to another area of memory.

It should be noted that, because each level entry has a fill index which specifies the fill 00 5 for the level, if the Fill Table is rebased, then the Level Table will be invalidated, and will r need to be rebased. The reverse, however, is not true.

The above features make it possible for the system to handle complex jobs that require a very large number of fill and level entries.

Overview of Preferred Controlling Program As mentioned previously, the preferred controlling program receives graphical objects from an application program that wishes to print a job using the rendering engine 880.

The controlling program builds a job containing a set of instructions for forwarding to the engine 880, together with data representing graphical objects. In the present context ajob represents one page of output.

When the preferred controlling program has prepared a complete job, the job is transferred to the host processor 870, which controls the rendering engine 880. The host processor 870 receives jobs from the preferred controlling program, provides memory for the engine 880, and instructs the engine 880 to start rendering the job. The host processor 870 tells the rendering engine 880 the location in memory of the job to be rendered, and instructs the engine 880 to start rendering, whereupon the engine 880 interprets the instructions and data in the job, and renders the page, without further involvement from the host processor. The output of the engine 880 is colour pixel data, which can be used by the printer 895.

3.1 Calculation of Level and Fill Tables 636114 The graphic objects received by the preferred controlling program are in ascending Z order. That is, each new object received by the preferred controlling program from the application will be painted over previous objects (ie. the "Painter's algorithm"). Note: the objects do not arrive in Y (scanline) order. The preferred controlling program cannot construct the job until all the objects have been received. If the controlling program were to construct job data for the first scanline before all the objects had arrived, then a succeeding object could also affect the first scanline, thereby invalidating what was already constructed.

Therefore the preferred controlling program needs to store all the objects in an internal object table before the controlling program completes its processing. For each object the information stored includes the following: extents of the object (the start and end scanline for the object); the fill details for the object (fill type, fill colour, fill opacity, image data if applicable); the fill rule; the absolute level number. Each incoming object is assigned a unique increasing level number; the composition operation (the operation to use when combining data for this object with lower levels); edge data, which includes data describing the shape of the edges.

The following data structure is used to hold data for an object in the internal table: struct object 636114.DOC -26int start_scanline; int end_scanline; fill_data; fill_rule; edge_data; composition_operation; int filllndex; int absLevel; int levellndex; startscanline endscanline filldata fillrule compositionoperation is the number of the scanline of the top of the object on the page; is the number of the scanline of the bottom of the object on the page; specifies the object's fill: this consists of the colour or image data and the opacity of the fill; is either non-zero winding or odd-even; is a code for the method used to combine colour from lower levels if the object is not opaque; is the index of the object's fill in the fill table (this is not known until the fill table is built, and the filllndex may change when a new fill table is built); filllndex 636114.DOC -27absLevel is the absolute level number of the object amongst all the objects on the page (the absLevel does not apply to a particular level table, and does not change); levellndex is the index of the object's level in the level table (this is not known until the level table is built, and levelIndex may change when a new level table is built); edgedata this includes data describing the shape of the edges, the edge data built into the final job for each edge includes the index of the level that the edge activates.

When the preferred controlling program has received all the objects from the application, the controlling program sorts the internal object table into ascending startscanline order. This table is used to process objects in scanline order, which is required to build fill and level tables.

The program then works its way down the page (ie. in ascending Y order), processing the objects in the table in scanline order.

The preferred controlling program builds an internal representation of the Fill Table, storing the following information in each entry: Type (eg. Flat/Image) Colour/opacity Blend data (if applicable) Image Data (if applicable) Object (a back pointer to the object with this fill) 636114.DOC -28- The back pointer to the Object containing the fill is useful in the processing outlined below this information is not built into the final fill table downloaded to the host system.

The preferred controlling program builds an internal representation of the Level Table, storing the following information in each entry: Fill Index (index of the fill for this level) Fill Rule (non-zero/odd-even) Need Below (true or false) 0 Object (a back pointer to the object on this level) 0 Absolute Level (unique level number for this level) The Object and Absolute Level fields are not built into the final level table downloaded to the host system.

For each object the controlling program checks whether the internal fill table is already full. If not, a new fill entry is created at the end of this table, and the index of the entry is recorded in the object's entry in the internal object table.

If the internal fill table is full then a new fill table, and new level table, must be started, at the scanline at which the object starts: First the current internal level and fill tables are converted and stored in the job as level and fill tables in the format required by the host rendering engine e Each object active across the scanline is split into two sub-objects one above the scanline and one from this scanline onwards.

Then new internal tables are created and initialized to contain the fills and levels of all objects which are active at the current scanline (ie. all objects whose extent includes the current scanline). Note that any object that was active across the scanline will 636114.DOC -29have been split, into two objects by the previous step. The program issues INSTSET_BUF instructions to point the engine's base registers at the new level and fill tables in the generated job.

The preferred controlling program then checks whether the level entry required for the new object will fit into the Level Table without overflow. If not then a new level table must be started, at the scanline at which the object starts: First the current level table is stored in the job.

Each object active across the scanline is split into two sub-objects one above the scanline and one from this scanline onwards.

e Then a new level table is created and initialized to contain the levels of all objects which are active at the current scanline. The program issues INSTSETBUF instructions to point the level table base register at the new level table.

3.2 Example 2 Turning now to Fig. 2 there is shown a simple example involving three objects A2, BO and C1. These objects have fills FA2, FBO and FC1 respectively.

The controlling program receives these objects from the application in the order BO, C1 and A2. BO is the lowest level object, then C1 with A2 being the highest level object.

The preferred controlling program calculates the extents of the objects, their fill specifications, and stores the objects in the internal table. When the objects have been sorted into scanline order, their order is A2, BO, C 1.

The preferred controlling program constructs table entries for the objects: After processing A2, these tables are 636114.DOC Fill Table Level Table After processing BO, these tables are: Fill Table Level Table After processing C1, these tables are: 636114.DOC -31 Fill Table Level Table Level Abs Level Fill Object 0 0 1 (FBO) BO 1 1 2 (FC1) Cl 2 2 0 (FA2) A2 Note that the new level entry for Cl is inserted before the entry for A2, and A2's entry is moved down in the table.

3.3 Example 3 Now turning to Fig. 3, there is shown an example with 10 graphical objects. In order to explain the processing which occurs when fill and level tables become full, consider the situation if the maximum fill and level table size were 8 entries.

The objects are received in painting order: AO, Al, A2, A3, A4, A5, A6, A7, C8, B9.

When sorted into scanline order, the order is: AO, Al, B9, A2, C8, A3, A4, A5, A6, A7.

The following table shows the start and end scanlines for each object with the objects sorted into ascending start scanline order: Scanline Ranges Object Start End 636114.DOC -32- AO 100 240 Al 120 260 B9 130 390 A2 140 290 C8 150 310 A3 160 310 A4 180 340 220 370 A6 300 420 A7 360 460 After A5 has been processed the fill and level tables are as follows: Fill Table Index Object Fill 0 AO FAO 1 Al FA1 2 B9 FB9 3 A2 FA2 4 C8 FC8 A3 FA3 6 A4 FA4 7 A5 636114.DOC -33- Level Table Level Abs Level Fill Object 0 0 0 (FAO) AO 1 1 1 (FA1) Al 2 2 3 (FA2) A2 3 3 5 (FA3) A3 4 4 6 (FA4) A4 5 7 (FA5) 6 8 4 (FC8) C8 7 9 2 (FB9) B9 When A6 is processed at scanline R=300, it is not possible to add the A6 fill entry to the fill table, so new tables must be built.

First the current fill and level tables are built as data for the rendering engine and placed in the job.

Objects A3, A4, A5, C8 and B9 are active across scanline R=300, so these objects are split into sub-objects: A3a, A3b, A4a, A4b, A5a, A5b, C8a, C8b, B9a and B9b. These new sub-objects are inserted into the sorted internal object table, in start-scanline order.

After splitting these objects the sorted internal object table looks like: Scanline Ranges Object Start End AO 100 240 Al 120 260 636114.DOC -34- B9a 130 299 A2 140 290 C8a 150 299 A3a 160 299 A4a 180 299 220 299 B9b 300 390 A3b 300 310 A4b 300 340 300 370 C8b 300 310 A6 300 420 A7 360 460 B9 130 390 After A5 has been processed the fill and level tables are as follows: Fill Table Index Object Fill 0 AO *FAO 1 Al FAl 2 B9a FB9 3 A2 FA2 6361 14.DOC 4 C8a FC8 A3a FA3 6 A4a FA4 7 A5a Level Table Level Abs Level Fill Object 0 0 0 (FAO) AO 1 1 1 (FA1) Al 2 2 3 (FA2) A2 3 3 5 (FA3) A3a 4 4 6 (FA4) A4a 5 7 (FA5) 6 8 4 (FC8) C8a 7 9 2 (FB9) B9a These tables are built into the job in the format required by the host rendering engine.

Then new fill and level tables are built, containing only the objects active at scanline R (ie. the objects whose vertical extent includes scanline R) which are A3b, A4b, A5b, C8b, and B9b.

The new internal fill and level tables are built containing entries pertaining to these objects: 636114.DOC 36 Fill Table Index Object Fill 0 B9b FB9b 1 C8b FC8b 2 A3b FA3b 3 A4b FA4b 4 A5b Level Table Level Abs Level Fill Object 0 3 2 (FA3b) A3b 1 4 3 (FA4b) A4b 2 5 4 (FA5b) 3 8 1 (FC8b) C8b 4 9 0 (FB9b) B9b After A6 is processed the tables become: 6361 14.DOC -37- Fill Table Index Object Fill 0 B9b FB9b 1 C8b FC8b 2 A3b FA3b 3 A4b FA4b 4 A5b A6 FA6 Level Table Level Abs Level Fill Object 0 3 2 (FA3b) A3b 1 4 3 (FA4b) A4b 2 5 4 (FA5b) 3 6 5 (FA6) A6 4 8 1 (FC8b) C8b .9 0 (FB9b) B9b Note: The entries in the fill table are in no particular order. When new fill entries are added, there is no need for reordering of entries. However, the order in the level table is important, since this determines which objects are painted on top of other objects. Thus: B9 appears above C8 in the rendered output because B9 entry in the level table comes after the entry for C8.

636114.DOC -38- After completion of processing for A6, the preferred controlling program commences processing A7 the next object in scanline order). The preferred controlling program then checks whether the fill and level entry data for this object A7 will fit into the new tables without overflow. If they can, the entries are added to their corresponding tables. If not, then new table(s) must be started, at the scanline at which the object starts.

The final job for this example that is passed to the rendering engine will look as follows: INST_SET_BUF LEVEL_TABLE_BASE, LEVTAB1 INSTSETBUF FILLTABLEBASE, FILLTAB1 INST_LOAD_EDGES_AND_RENDER 100,[No edge data] render the first 100 scanlines (no edge data applicable) INST_LOAD_EDGES_AND_RENDER 20,[Edge data for AO] Load the edges for AO and render the next 20 scanlines INST_LOAD_EDGES_AND_RENDER 10, [Edge data for Al] Load the edges for Al and render the next 10 scanlines INST_LOAD_EDGES_AND_RENDER 10, [Edge data for B9a] INST_LOAD_EDGES_AND_RENDER 10, [Edge data for A2] INST_LOAD_EDGES_AND_RENDER 10, [Edge data for C8a] INST_LOAD_EDGES_AND_RENDER 20, [Edge data for A3a] INST_LOAD_EDGES_AND_RENDER 40, [Edge data for A4a] INST_LOAD_EDGES_AND_RENDER 80, [Edge data for INST_SET_BUF LEVEL_TABLE_BASE, LEV_TAB2 INSTSETBUF FILLTABLEBASE, FILLTAB2 636114.DOC -39- INST_LOAD_EDGES_AND_RENDER 60, [Edge data for A3b, A4b, B9b,C8b and A6] INST_LOAD_EDGES_AND_RENDER 640, [Edge data for A7] Load edges for A7 and render the rest of the page INST EOJ LEV TAB1: <first level table> FILL TAB1: <first fill table> LEV TAB2: <second level table> FILL TAB2: <second fill table> EDGE DATA: <Edge data for the graphical objects> The host controlling program on the host processor 870 will then receive this instruction job and store the job in memory 890 and inform the rendering engine 880 of the job's address in memory 890. The rendering engine 880 will then proceed to perform the instructions. The first instruction in this example instruction job is the INST_SETBUF instruction telling the rendering engine to set the address in the level table register, namely the LEVEL_TABLE_BASE register, to an address LEVTAB1 offset from the address of the instruction job. After completion of this instruction, the 636114.DOC rendering engine will then proceed to process the next instruction, where the address in the fill table register is set in similar fashion. The rendering engine will then proceed to process the INST_LOAD_EDGES_AND_RENDER instructions in turn accessing fill and level data from the tables LEV_TAB1 and FILL_TAB1, if required, via the current addresses in the registers. This continues until the rendering engine again encounters the INSTSET_BUF instruction. The latter instruction tells the rendering engine to reset the address in the level table register to an address LEV_TAB2 offset from the address of the instruction job. After completion of this instruction, the rendering engine will then proceed to process the next instruction, where the address in the fill table register is set in similar fashion. The rendering engine will then proceed to process the INST_LOAD_EDGES_AND_RENDER instructions in turn accessing fill and level data from the tables LEV_TAB2 and FILL_TAB2, if required, via the new addresses in the registers. After completion of the processing of the latter INST_LOAD_EDGES_AND_RENDER instructions the rendering engine encounters an end of job instruction ie. INST_EOJ and the instruction job is terminated.

3.4 Method Turning now to Figs. 4A and 4B there is shown a flow chart of a method for generating an instruction job containing a set of instructions for forwarding to the rendering engine, together with data representing graphical objects. This method 400 is implemented as a software program for controlling the operation of the rendering engine, herein before called the preferred controlling program. The preferred controlling program may be stored on computer readable media, which program is loaded from such media and executed on the client processor.

636114.DOC -41 The method 400 commences at step 410 when the method 400 initially receives an application job containing graphical objects from the application program. After commencing 410, the method 400 proceeds to step 415, where a counter 'absLevel' is set to 0, and new fill and level tables are initialized. Then the method 400 proceeds to a loop for receiving and processing each object of the application job. This loop initially tests at step 420 whether there are any more remaining graphical objects from the job that have not been processed. If this test 420 reveals there are no more graphical objects to be processed, the method 400 exits the loop and proceeds to step 445. Otherwise, the method 400 proceeds to step 425, where the next object in the application, that has not yet been processed, is set for processing. After completion of step 425, the method 400 proceeds to step 430, where the fill, edge, level and extent data of the graphical object are determined and are set in a temporary variable 'Object'. After step 430, the method then in step 435 sets the variable Object.abslevel in the new entry of the internal object table to the current value of the counter 'abslevel' and then increments the counter 'abslevel' by one. After step 435, the method then stores in step 440 the current fill, edges, level and extent data of the current object in the new entry in the internal object table. After completion of step 440, the method returns to step 420 of the loop for processing any remaining objects from the application.

If step 420, reveals there is no more graphical objects to be processed, then the method proceeds to step 445. In step 445, the method 400 then sorts the objects in the internal object table into ascending start-scanline order. In this context it should be noted that edge data for each graphical object has a y co-ordinate value measured from the top of the page indicating the start of the edge(s) of the object (See Example 1).

636114.DOC -42- After completion of step 445, the method 400 proceeds to step 416, where empty fill and level tables are initialized. The method 400 then in step 418 issues INSTSETBUF instructions to be included in the instruction job pointing to the addresses of these tables for subsequent use by the rendering engine. The method 400 then proceeds to a further loop.

This further loop builds an instruction job for the rendering engine after the method 400. The further loop processes each object in the internal object table in turnin scanline order (the table has already been sorted into scanline order during step 445). The loop initially tests, in step 455, whether there are any more remaining objects in the internal object table that have not yet been processed for inclusion in the instruction job.

If the test 455 returns in the affirmative (Yes), the method 400 proceeds to step 460. In step 460 the next object in scanline order in the internal object table that has not yet been processed for inclusion in the instruction job (hereinafter called the current object), is set for processing. After step 460, the method 400 proceeds to step 462.

The method in step 462 checks whether the current object's fill has already been included in the fill table. If this check returns in the affirmative (Yes), then it is not necessary to add the current object's fill entry and level entry to the fill and level tables respectively, and the method proceeds to step 470.

Otherwise, if the check 462 returns in the negative (No) then the method proceeds to step 465. The method 400. in step 465, tests whether the current object's fill data will fit in the current fill table. If this test 465 returns in the affirmative (yes), then the method 400 proceeds to step 468, where the current object fill data is added to the current fill table.

After the fill data is added to the current fill table in step 468, the method 400 proceeds to step 470, where the method 400 tests whether the current object's level data will overflow 636114.DOC -43the level table. If this test 470 returns in the negative then the method 400 proceeds to step 475, where a sub-process herein called the insertlevel sub-process is called for adding the current object's level data to the level table. This sub-process is described below in more detail with reference to Fig. 7. After completion of step 475, the method 400 proceeds to step 463, where the method adds appropriate edge render instructions and edge data concerning the object to the instruction job, and then returns to step 455, for processing the next object in the internal object table (if any).

On the other hand, if step 465 returns in the negative that is the internal fill table is already full and the current object's fill data will not fit into the current fill table, then the method proceeds to step 495. The method, in step 495, then stores the current fill and level tables in the instruction job and initializes new internal fill and level tables.

After completion of step 495, the method 400 in step 497 sets the current scanline to the start scanline of the object in question. Step 499 then calls a sub-process 900 entitled split_objects, seen in Fig. 9. The sub-process 900 splits each object, active across the current scanline, into two objects one above the scanline and one from the current scanline downwards.

After conclusion of the split_objects sub-process 900, the method 400 returns to step 402 where a sub-process herein called the buildfill_table sub-process is instigated for building a new internal fill table based on objects that are active at the current scanline. This buildfill_table sub-process is described below in more detail with reference to Fig. 5. After completion of the buildfill_table sub-process in step 402, the method proceeds to step 404, where a sub-process for building a new level table is called, herein after called the build_level_table sub-process. This build_level_table sub-process inserts the levels of the object active at the current scanline. The build_level_table sub- 636114.DOC -44process may have to move existing entries in the new level table to keep the entries in correct Z order. The build_level_table sub-process is described below in more detail with reference to Fig. 6. After the completion of the build_level_table sub-process in step 404, the method proceeds to step 406.

The method 400 in step 406 then issues INST_SETBUF instructions for inclusion in the instruction job for subsequent use by the Fill and Level table base registers in the rendering engine. After completion of step 406, the method 400 returns to step 463, described above, and for subsequent processing any remaining objects in the internal object table.

If however step 470 returns in the affirmative (Yes), that is the internal level table is already full or nearly full and the current object's level data will not fit into the current level table, then the method proceeds to step 480. The method 400, in step 480, then stores the current level table in the instruction job and initializes a new level table.

After completion of step 480, the method 400 proceeds to steps 481 and 483 which replicate steps 497 and 499 described above and which operate to set up and call the split objects sub-process 900. On conclusion of the splitobjects sub-process 900, the method 400 returns to step 485, which calls the build_level_table sub-process for building a new level table. The latter sub-process is described below in more detail with reference to Fig. 6. After completion of the sub-process in step 485, the method proceeds to step 490.

The method 400 in step 490 issues INST_SETBUF instructions to be included in the instruction job for subsequent use by the Level table base register in the rendering engine.

After step 490, the method returns to step 463, described above, prior to processing any remaining objects in the internal object table.

636114.DOC If the step 455 returns in the negative, that is all objects in the internal object table have been processed, the method 400 then proceeds to step 408. The method 400 in step 408 builds the current fill and level tables into the instruction job. The job is then sent, in step 412 to the rendering engine's host system. After completion of step 412, the method terminates 414.

Turning now to Fig. 5, there is shown a flowchart of the buildfill_table sub-process for building a new internal fill table. This build fill_table sub-process is called by step 402 of the method, and is called at a particular scanline on the page, when no more fills could be added to the old table. The buildfill_table sub-process builds a new fill table containing the fills pertaining to the objects which are active in, that is whose extent includes, the current scanline. The current scanline is the start scanline of the object currently being processed by the method.

The buildfill_table sub-process commences at step 505, where the value of the current scanline (currScanline) is received from the calling step. The buildfill_table sub-process then proceeds to enter a loop where each object of the internal object table is processed in turn in scanline order. The buildfilltable sub-process enters the loop at step 515, where a test is made whether there are any more remaining objects in the internal object table that have not yet been processed by the sub-process. If the step 515 determines that there are no more objects to be processed, the buildfilltable sub-process returns 520 to step 402 of the method. Otherwise, the buildfill_table sub-process proceeds to step 530.

The buildfilltable sub-process in step 530 gets the next object in scanline order from the internal object table that has not yet been processed by the build ill_table subprocess. The buildfill_table sub-process then proceeds to step 535, where the buildfill_table sub-process tests whether the current object's start_Scanline is greater 636114.DOC -46than or equal to currScanline. If the test returns in the affirmative, then the current object is not active at the current scanline (viz the current object commences its activity after the scanline currScanline), and the build fill_table sub-process returns 525 to step 402 of the method. It should be noted that any subsequent objects to be processed in the internal object table will also not be active at the scanline currScanline as they are arranged in ascending order and consequently the sub-process may terminate 525. Otherwise, the build Jill_table sub-process proceeds to step 540.

The build fill_table sub-process in step 540 tests whether the current object's EndScanline is less than currScanline. If step 540 returns in the affirmative, then the current object has finished its activity before the scanline currScanline, and the build fill_table sub-process returns to step 515 to process the next object in the internal object table. Otherwise, if step 540 returns in the negative, then the current object is active on the scanline currScanline, and the buildfill_table sub-process proceeds to step 545.

The buildfill_table sub-process in step 545, then determines if the current fill table, that is the new fill table, is full. If the step 545 returns in the affirmative, then a fill table is unable to be built for scanline currScanline and the build fill_table sub-process proceeds to step 550. The build fill_table sub-process in step 550 generates an error message for inclusion in the instruction job indicating that layering needs to be performed at this scanline. The buildfill_table sub-process then returns at step 555 to the calling step passing this error message.

If the step 545 returns in the negative, then the build ill_table sub-process proceeds to step 560 where the current object's fill is added to the end of the fill table. The step 560 then sets the variable Object.fillIndex of the current object to the index of the new entry in 636114.DOC -47the fill table. It should be appreciated that edge data associated with this Object including the Object.fillIndex and Object.levellndex are included in the instruction job for processing by the rendering system. The rendering system is able to access the fill and level data indirectly when needed by referencing the variables Object.fillIndex and Object.levellndex that respectively point to the fill and level data in the fill and level tables.

After completion of step 560, the build Jill_table sub-process returns to step 515 for processing of any remaining objects in the internal object table.

Turning now to Fig. 6, there is shown a flowchart of the build_level_table sub-process for building a new level table. This build_level_table sub-process can be called by either steps 404 and 485 of the method. It should be noted that this build_level_table subprocess is called at a particular scanline on the page, when no more levels could be added to the old table. The build_level_table sub-process builds a new level table containing the levels pertaining to the objects which are active in, that is whose extent includes, the current scanline. The current scanline is the start scanline of that object currently being processed by the method. As each such active level is inserted into the level table, the level order, ie. the Z value, is maintained, so in some cases entries are shuffled down to make space for new level entries. For each object whose level is added to the table, the level index is set to the index of the object's level.

The build_level_table sub-process commences at step 605, where the value of the current scanline (herein called currScanline) is received from the calling step (404, 485).

The build_level_table sub-process then proceeds to enter a loop where each object of the internal object table is processed in turn in scanline order. The build_leveltable subprocess enters the loop at step 610, where a test is made whether there are any more 636114.DOC -48remaining objects in the internal object table that have not yet been processed by the build_level_table sub-process. If the step 610 determines that there are no more objects to be processed, the build_level_table sub-process returns 625 to calling step (404, 485) of the method. Otherwise, the build_level_table sub-process proceeds to step 615.

The build_level_table sub-process in step 615 gets the next object in scanline order from the internal object table that has not yet been processed (by the build_level_table sub-process). The buildlevel_table sub-process then proceeds to step 620, where the buildfill_table sub-process tests whether the current object's start_Scanline is greater than currScanline. If the tests returns in the affirmative, then the current object is not active at the current scanline (viz the current object commences its activity after the scanline currScanline), and the build_level_table sub-process returns 630 to the calling step 404, or 485 of the method. It should be noted that any subsequent objects to be processed in the internal object table will also not be active at the scanline currScanline as they are arranged in ascending order and consequently the sub-process may terminate 630.

Otherwise, the build_level_table sub-process proceeds to step 635.

The build_level_table sub-process in step 635 tests whether the current object's End_Scanline is less than currScanline. If step 635 returns in the affirmative, then the current object has finished its activity before the scanline currScanline, and the build level_table sub-process returns to step 610 to process the next object in the internal object table. Otherwise, if step 635 returns in the negative, then the current object is active on the scanline currScanline, and the build_level_table sub-process proceeds to step 640.

The build_level_table sub-process in step 640, then determines if the current level table, that is the new level table, is full. If the step 640 returns in the affirmative, then a 636114.DOC -49level table is unable to be built for scanline currScanline and the build level table subprocess proceeds to step 645. The build_level_table sub-process in step 645 generates an error message for inclusion in the instruction job indicating that layering needs to be performed at this scanline. After step 645, the build_level_table sub-process then returns at step 650 to the calling step 404,485) passing this error message.

If the step 640 returns in the negative, then the build_level_table sub-process proceeds to step 655. In step 655 a sub-process herein called insert_level sub-process is called for adding the current object's level to the level table. This sub-process is described below in more detail with reference to Fig. 7. After completion of step 655, the build_level_table sub-process returns to step 610 for processing of any remaining objects in the internal object table.

Turning now to Fig. 7 there is shown a flowchart of the insert_level sub-process for inserting an object level into a new level table. This insert_level sub-process is called by step 655 of the build_level_table sub-process and step 475 of the method 400. It should be noted that in this insert_level sub-process, as each active level is inserted into the level table, the level order is maintained, so in some cases entries are shuffled down to make space for new level entries. For each object whose level is added to the table, the level index is set to the index of the object's level.

The insert_level sub-process commences at step 705 when it is called by step 655 of the build_level_table sub-process or step 475 of the method 400. The insert_level subprocess then enters a loop for processing each entry in the Level table in turn. The insert_level sub-process enters the loop at step 715, where it sets the current level to the next level from the Level Table that has not yet been processed. Initially, it commences with the first level in the level table.

636114.DOC After step 715, the insert_level sub-process then tests at step 720 whether there are any more levels in the table. If the test 720 returns in the affirmative, the insertlevel subprocess proceeds to a further test 735. Step 735 tests whether the value of Level.absLevel of the current entry in the level table is greater than the value Object.absLevel of the level data of the current object to be inserted in the level table. If the test 735 returns in the affirmative, the insert_level sub-process then proceeds to step 740. Namely, if both these tests 735 and 720 return in the affirmative, this indicates that the new entry Object is to be placed between the current level and the next level of the level table. This is achieved by steps 740, 745, 750 and 755. The insert_level sub-process in step 740, moves the entries in the level table after the current level down by one place. After completion of step 740, the insertlevel sub-process proceeds to step 745, where the levellndex in each object, whose level entry is moved, is adjusted to reflect the object's current place in the level table. The insert_level sub-process then proceeds to step 750, where the new level entry is inserted into the level table at the current position. After step 750, the insert_level subprocess proceeds to step 755, where the insert_level sub-process sets the newLevel.Object to Object, that is inserts the level data into the new entry of the Level table. Also during this step 755, the insert_level sub-process sets the Object.levellndex of the current object to the current index of the new entry of the level table and sets the newLevel.absLevel of the new entry of the level table to the Object.absLevel of the current object. After completion of step 755, the insert_level sub-process terminates and returns to the calling step.

On the other hand, if test 735 returns in the negative, then the insert_level sub-process returns to step 715 to process the next entry in the level table.

636114.DOC -51 Additionally, if test 720 returns in the negative, the insert_level sub-process proceeds to step 725, where the new entry is added to the end of the level table, namely it sets the newLevel.Object to the current Object. Also in this step 725, the insert_level sub-process sets the Object.levelIndex of the current object to the index of the new entry of the level table and sets the newLevel.absLevel to the Object.absLevel of the current object.

After completion of step 725, the insert_level sub-process terminates 730 and returns to its calling step.

Turning now to Fig. 9, the split_objects sub-process 900 can now be described. After entry to the sub-process 900 at step 902, step 904 initially gets an object from the internal object table. Step 906 tests if there are any objects remaining in the table and, if not, the sub-process 900 ends at step 908, which causes a return to the calling step.

Where the internal object table possesses one or more objects, the current object is set to be the next from the table in step 910. Step 912 then tests the current object to determine whether or not the object extends over the current scanline. This is done through a comparison of start and end scanlines of the current object with the current scanline. If the object does not extend over the current scanline, no processing is performed on that object and the sub-process 900 returns to step 904 to get the next object from the internal object table.

Where the current object spans the current scanline, step 912 passes that object to steps 914, 916 and 918 where the current object Obj is split into two objects, Oa and Ob.

The object Oa is that part of the current object Obj above the current scanline and the object Ob is that part from the current scanline downwards. In step 914 the object Oa has its graphic object values set to those of the current object Obj excepting that the end scanline for Oa is set to be the current scanline minus one. Step 916 follows substantially 636114.DOC 52 similarly for the object Ob excepting that the edge data for Ob is set to be that for Obj below the current scanline. In step 918, the object Oa is used to replace the current object Obj in the internal object table, and the object Ob is inserted into the internal object table in order of the starting scanline. Step 904 then follows as before.

4.0 Example At a high level, when a user of the client computer 810 operates the application 830 (eg. an image production tool) and desires to print a created image, the application 830 and the controlling program (operating system) 840 create a print job that includes a page description of the image to be printed. The print job is transmitted via the network to a printer device 860 whereby the program represented by the flowchart of Figs. 4A-4C analyses the print job and the graphical content thereof. Where the content is sufficiently complex to exceed a nominal size of fill and level tables required to be established prior to pixel sequential rendering to be performed by the apparatus 880, the processor 830 executes the program, to create multiple fill and level tables relating to bands of scanlines of the page image to be printed. The multiple fill and level tables each fall within a processing constraint size to which the apparatus 880 is configured. That constraint size may typically be established by corresponding table sizes in silicon hardware, or by a software processing capacity where the pixel sequential rendering is founded in software.

The fill and level tables so formed are then forwarded to the apparatus 880 as complementary pairs for consecutive bands of the page image. The apparatus 880 processes each pair of tables and the graphic objects thereby described to produce a band of scanlines of the page image corresponding thereto. The bands are output to the printer engine 895 for hard copy reproduction. Once all bands have be processed, the printing function is concluded.

636114.DOC -53- As mentioned above, the rendering engine generates edge data of the graphical objects where each edge will contain an index to a level entry. In this way, the rendering engine is able to indirectly reference the fill and level data, contained in the fill and level tables, corresponding to an edge of an object when processing that edge. It does this by referencing the level data referenced by the level index associated with the edge, which level data contains in turn a fill index which references the fill data associated with the edge. However, as shown above, level indices can be reassigned when new entries are inserted into the level table. This means that edge data cannot be finalized till table data is finalized, ie. at the end of a page or when tables are output due to them becoming full.

The aforementioned methods comprise a particular control flow. There are many other variants of the methods which use different control flows without departing the spirit or scope of the invention.

Industrial Applicability It is apparent from the above that the arrangements described are applicable to the computer graphics industries.

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.

636114.DOC

Claims (19)

1. A method of generating an instruction job for instructing a rendering apparatus to render a plurality of graphical objects to an output associated with a plurality of scanlines, the method comprising the steps of: building a plurality of fill and level tables, wherein each said fill table and level table comprises a plurality of entries, where each said entry of a fill table defines a fill of a corresponding said graphical object and each said entry of a level table defines a level of a corresponding said graphical object; and adding instructions to the instruction job, wherein said instructions comprise a plurality of register instructions, each register instruction of a first set of said plurality of register instructions being adapted to set a first register of the rendering apparatus for referencing a corresponding said fill table and each register instruction of a second set of said plurality of register instructions being adapted to set a second register of the rendering apparatus for referencing a corresponding said level table.

2. A method as claimed in claim 1, wherein each register instruction of said plurality of register instructions is in the form of one instruction name having two arguments, one argument for identifying which of the first or second registers is to be set, the other argument identifying the address for referencing said fill or level table.

3. A method as claimed in claim 1 or 2, said method further comprising the step of: adding said fill and level tables to the instruction job.

636114.DOC

4. A method as claimed in claim 1, 2 or 3 wherein said fill tables are each limited in Ssize to a first predetermined fixed number of bytes and said level tables are each limited in size to a second predetermined fixed number of bytes. 00 5

5. A method as claimed in any one of claims 1 to 4, wherein said fill tables are each C limited in size to a first predetermined fixed number of bytes and said level tables are each limited in size to a second predetermined fixed number of bytes, and said building step comprises the sub-steps of: building a plurality of said fill tables, wherein each said fill table comprises fills of those corresponding graphical objects which have a presence in at least one of a number of contiguous ones of said scanlines; and building a plurality of said level tables, wherein each said level table comprises levels of those corresponding graphical objects which have a presence in at least one of a number of contiguous ones of said scanlines.

6. A method as claimed in any one of claims 1 to 5, wherein said fill tables are each limited in size to a first predetermined fixed number of bytes and said level tables are each limited in size to a second predetermined fixed number of bytes, and said building step comprises the sub-steps of: determining, for each graphical object, a scanline at which the graphical object starts; processing each graphical object in turn in scanline order according to their said determined scanline; wherein the processing comprises, for a current said graphical object, the sub-steps of: 636114 -56- determining whether adding an entry defining a fill of the c current graphical object to the current fill table will cause the current fill table to exceed said first number of bytes; and if so 00 5 storing said current fill and level tables in said Cinstruction job; initializing new current fill and level tables; and adding said entry defining the fill of the current graphical object to the new current fill table; otherwise adding said entry defining the fill of the current graphical object to the current fill table; determining whether adding an entry defining a level of the current graphical object to the current level table will cause the current level table to exceed said second number of bytes; and if so: storing said current level table in said instruction job; initializing a new current level table; and adding said entry defining the level of the current graphical object to the new current level table; otherwise adding said entry defining the level of the current graphical object to the current level table. 636114 -57-

7. A method according to claim 6 wherein each of steps and comprise splitting each currently active graphical object at a current scanline at which a size of said tables is exceeded and assigning the split objects into respective ones of said (Ni 00 5 current level and fill tables, and said new level and fill tables.

8. A method according to claim 7, wherein said splitting comprises dividing each said currently active graphical object into two graphical objects, one above said current scanline and one including and beneath said current scanline, said two graphical objects including like fill and level values retained in the corresponding current and new fill and level tables.

9. A method according to claim 8 wherein for said above graphical object, said fill and level values correspond to those of said currently active graphical object, and for said below graphical object, said fill value corresponds to that of said currently active graphical object and said level value is adjusted relative to remaining ones of said graphical objects to be rendered and commencing at a scanline subsequent in rendering order to said current scanline.

10. A method according to claim 7, 8 or 9 wherein said fill and level tables form complementary pairs related to portions of said rendering job between certain scanlines. 636114 -58-

11. Computer program for generating an instruction job for instructing a rendering apparatus to render a plurality of graphical objects to an output associated with a plurality of scanlines, the computer program comprising: code for building a plurality of fill and level tables, wherein each said fill table and level table comprises a plurality of entries, where each said entry of a fill table defines a fill of a corresponding said graphical object and each said entry of a level table defines a level of a corresponding said graphical object; and code for adding instructions to the instruction job, wherein said instructions comprise a plurality of register instructions, each register instruction of a first set of said plurality of register instructions being adapted to set a first register of the rendering apparatus for referencing a corresponding said fill table and each register instruction of a second set of said plurality of register instructions being adapted to set a second register of the reridering apparatus for referencing a corresponding said level table.

12. A computer program as claimed in claim 11, wherein each register instruction of said plurality of register instructions is in the form of one instruction name having two arguments, one argument for identifying which of the first or second registers is to be set, the other argument identifying the address for referencing said fill or level table.

13. A computer program as claimed in claim 11 or 12, said program further comprising: code for adding said fill and level tables to the instruction job. 636114.DOC -59-

14. A computer program as claimed in claim 11, 12 or 13 wherein said fill tables are Seach limited in size to a first predetermined fixed number of bytes and said level tables are each limited in size to a second predetermined fixed number of bytes. 00 5

15. A computer program as claimed in any one of claims 11 to 14, wherein said fill N tables are each limited in size to a first predetermined fixed number of bytes and said level tables are each limited in size to a second predetermined fixed number of bytes, and said code for building comprises: code for building a plurality of said fill tables, wherein each said fill table comprises fills of those corresponding graphical objects which have a presence in at least one of a number of contiguous ones of said scanlines; and code for building a plurality of said level tables, wherein each said level table comprises levels of those corresponding graphical objects which have a presence in at least one of a number of contiguous ones of said scanlines.

16. A computer program as claimed in any one of claims 11 to 15, wherein said fill tables are each limited in size to a first predetermined fixed number of bytes and said level tables are each limited in size to a second predetermined fixed number of bytes, and said code for building comprises: code for determining, for each graphical object, a scanline at which the graphical object starts; code for processing each graphical object in turn in scanline order according to their said determined scanline; wherein said code for processing comprises: 636114 Scode for determining whether adding an entry defining a fill of the current Sgraphical object to the current fill table will cause the current fill table to exceed said first number of bytes and, if so, to thereby store said current fill and level tables in said instruction job; o") 00 5 initialize new current fill and level tables; and add said entry defining the fill of the current graphical o") Sobject to the new current fill table; and if not, to thereby add said entry defining the fill of the current graphical object to the current fill table; code for determining whether adding an entry defining a level of the current graphical object to the current level table will cause the current level table to exceed said second number of bytes and, if so, to thereby: store said current level table in said instruction job; initialize a new current level table; and add said entry defining the level of the current graphical object to the new current level table; and if not, to thereby add said entry defining the level of the current graphical object to the current level table.

17. A computer program according to claim 16 wherein the adding of entries to said new tables is performed by code for splitting each currently active graphical object at a 636114 -61 Scurrent scanline at which a size of said tables is exceeded and assigning the split objects Sinto respective ones of said current level and fill tables, and said new level and fill tables.

18. A computer program according to claim 17, wherein said code for splitting divides C., 00 5 each said currently active graphical object into two graphical objects, one above said current scanline and one including and beneath said current scanline, said two graphical objects including like fill and level values retained in the corresponding current and new fill and level tables.

19. A computer program according to claim 18 wherein for said above graphical object, said fill and level values correspond to those of said currently active graphical object, and for said below graphical object, said fill value corresponds to that of said currently active graphical object and said level value is adjusted relative to remaining ones of said graphical objects to be rendered and commencing at a scanline subsequent in rendering order to said current scanline. A computer program according to claim 17, 18 or 19 wherein said fill and level tables form complementary pairs related to portions of said rendering job between certain scanlines. 21. Apparatus for generating an instruction job for instructing a rendering apparatus to render a plurality of graphical objects, said apparatus comprising: means for building a plurality of fill and level tables, wherein each said fill table and level table comprises a plurality of entries, where each said entry of a fill table defines 636114 62 a fill of a corresponding said graphical object and each said entry of a level table defines a level of a corresponding said graphical object; and means for adding instructions to the instruction job, wherein said instructions comprise a plurality of register instructions, each register instruction of a first set of said plurality of register instructions being adapted to set a first register of the rendering apparatus for referencing a corresponding said fill table and each register instruction of a second set of said plurality of register instructions being adapted to set a second register of the rendering apparatus for referencing a corresponding said level table. 22. A system for rendering graphic objects, wherein the system comprises: a computer program for generating an instruction job for instructing a rendering apparatus to render a plurality of graphical objects, the computer program comprising: code for building a plurality of fill and level tables, wherein each said fill table and level table each comprise a plurality of entries, where each said entry of a fill table defines a fill of a corresponding said graphical object and each said entry of a level table defines a level of a corresponding said graphical object; code for adding instructions to the instruction job, wherein said instructions comprise a plurality of register instructions, each register instruction of a first set of said plurality of register instructions being adapted to set a first register of a rendering apparatus for referencing a corresponding said fill table and each register instruction of a second set of said plurality of register instructions being adapted to set a second register 636114.DOC -63- of a rendering apparatus for referencing a corresponding said level table; and code for sending said instruction job to the rendering apparatus; and rendering apparatus for rendering said graphical objects in response to receiving said instruction job, wherein said rendering apparatus comprises: memory for storing said fill and level tables; and rendering engine for generating colour output, for each pixel in turn, in response to instructions in said instruction job; wherein said rendering engine comprises: a first register and a second register for referencing a said fill table and a said level table respectively in said memory; and a controller for interpreting said register instructions in said instruction job and setting said registers to an address of said fill and level tables in said memory. 23. A method of generating an instruction job for instructing a rendering apparatus to render a plurality of graphical objects, the method substantially as described with reference to Figs. 4A-4C 5, 6, 7 and 9 of the accompanying drawings. 24. Apparatus for generating an instruction job for instructing a rendering apparatus to render a plurality of graphical objects, the method substantially as described herein with reference to Figs. 4A-4C, 5, 6, 7, 8 and 9 of the accompanying drawings. 636114.DOC -64- Computer program for generating an instruction job for instructing a rendering apparatus to render a plurality of graphical objects, the method substantially as described herein with reference to Figs. 4A-4C, 5, 6, 7 and 9 of the accompanying drawings. 26. A system for rendering graphic objects, the system substantially as described herein with reference to Figs. 4A-4C, 5, 6, 7, 8 and 9 of the accompanying drawings. DATED this TWENTIETH Day of JUNE 2003 CANON KABUSHIKI KAISHA Patent Attorneys for the Applicant SPRUSON&FERGUSON 636114.DOC