AU769956B2 - Conversion of vectorized paths into a renderable format - Google Patents

Description

S&FRef: 551271

AUSTRALIA

PATENTS ACT 1990 COMPLETE SPECIFICATION FOR A STANDARD PATENT

ORIGINAL

Name and Address of Applicant: Actual Inventor(s): Address for Service: Canon Kabushiki Kaisha 30-2, Shimomaruko 3-chome, Ohta-ku Tokyo 146 Japan Alexander Bgrab1i L2\ AL/ Spruson Ferguson T O St Martins Tower,Level 31 Market Street Sydney NSW 2000 Conversion of Vectorized Paths into a Renderable Format Invention Title: ASSOCIATED PROVISIONAL APPLICATION DETAILS [33] Country [31] Applic. No(s) AU PQ7285 [32] Application Date 03 May 2000 The following statement is a full description of this invention, including the best method of performing it known to me/us:- 5815c -i- CONVERSION OF VECTORIZED PATHS INTO A RENDERABLE FORMAT Field of the Invention The present invention relates to graphic object rendering systems, and in particular to the efficient conversion of vectorized path data into a format that is both compact and suitable for fast rendering.

Background Fig. 1 shows a graphic object rendering system 100 in which graphic objects 102 are input and converted to a binary page description 106 by a graphic object processing module 104. The page description 106 is passed to a rendering engine 108 which produces pixels 110 which may be output to any of a display screen 113, printer 114 or storage file 116. The rendering engine 108 can either be implemented in hardware or software. In order to maximize throughput, it is important that the data format produced by the graphic object processing module 104 be convenient for the rendering engine 108 15 to process. It is also beneficial to have this format as compact as possible, in order to *e *e reduce any intermediate storage requirements. For the same reasons, the graphic object processing module 104 must perform its tasks quickly and efficiently.

Summary of the Invention ooooe Whilst the module 104 has many tasks, the present disclosure is concerned with the handling of graphic object shape outlines, and to a method and a resulting data format for the handling of graphic object shape outlines which addresses, or at least aspires to address, one or more of the aforementioned goals.

According to a first aspect of the invention, there is provided a method of converting data defining a vectorized path into a renderable format, said method comprising the steps of: identifying adjacent pairs of points within said path; 551271.doc -2for each said pair of points, forming a straight line segment using a vectorized data format; and forming a renderable data format for each said segment by modifying said vectorized data format for at least one said segment, said modifying comprising compensating for a scanline error between adjacent ones of said segments when a change of direction occurs between two adjacent ones of said segments.

Other aspects of the invention, including an apparatus for implementing the aforementioned method and a computer program, a computer readable medium having recorded thereon a computer program for implementing the method described above, and a system for rendering are also disclosed.

Brief Description of the Drawings At least one embodiment of the present invention will now be described with reference to the drawings, in which: Fig. 1 is a block diagram showing major components of a rendering system; Fig. 2 shows the processing pipeline for graphic object shape outlines; Figs. 3A and 3B illustrate the task of a vectorization engine; S. Figs. 4A and 4B illustrate the structure of a vectorized path, and provide an example of a vectorized path description; Figs. 5A to 5J show the type of segments used in the arrangements described and their purpose; Fig. 6 is a flow chart of an algorithm used to process a vectorized path; Fig. 7 illustrates the concept of half scanlines, and the effective scanline range of •segments; Fig. 8 illustrates an application of the step-vector segment; 551271.doc -3- Fig. 9 is a continuation of the flow chart of Fig. 6 for the case where there is an x-offset; Fig. 10 is a continuation of the flow chart in Fig. 6 for the case where there is no x-offset; Fig. 11 illustrates the scanline conversion algorithm used by a typical rendering engine; Fig. 12 is an example of the output of a path conversion algorithm; and Fig. 13 is a schematic block diagram representation of a computer system in which an embodiment may be implemented.

Detailed Description Fig. 2 shows a block diagram of the shape outline processing pipeline 200 found within the graphic object processing module 104 previously presented in Fig. 1. A shape outline of a graphic object 202 is first vectorized by a vectorizing engine 206, producing a vectorized path 208, or simply a "path object". Figs. 3A and 3B illustrate examples of the function of a vectorizing engine 206 in which sufficient points are placed on curves of shape outlines 302 to produce straight line segments. A resulting vectorized path 304 is formed of only straight line segments. The specific workings of the vectorization engine 206 does not concern the present disclosure and, as such are known in the art, need not be discussed further.

Fig. 4A depicts the structure of a path object 208. A path 214 is formed of a set S, of path edges 216. Each path edge 216 points to a set 218 of coordinates 220 describing the outline of a shape. The outline is defined by joining adjacent points in the path edge 216 using straight line segments. Fig. 4B shows an example of two paths defining two polygons 402 and 404. The corresponding path objects may be defined as: 551271.doc -4path: 2 edges edge 0: 5 points edge 1: 5 points x,y 100.0, 100.5 x,y 140.0, 140.5 100.0, 200.5 160.0, 140.5 200.0, 200.5 160.0, 160.5 200.0, 100.5 140.0, 160.5 100.0, 100.5 140.0, 140.5 As seen from the above example, each path edge has an associated direction, defined by the order in which points defining the path edge are sequenced. Referring back to Fig. 2, it is this path that is fed as an input into a path converter module 210, which produces the binary format 212 required by the rendering engine 108.

In order to understand the task of the path converter 210, the workings of the rendering engine 108 should be first explained. The rendering engine 108, or "renderer" as it is sometimes known in the art, typically processes graphic objects in increasing scanline order for rasterised output. For each such scanline, graphic objects are examined in increasing x-order (ie. left to right). When an edge is encountered, the direction of the edge informs the renderer 108 as to whether the shape formed by the edge is being entered or exited, depending on the filling rule applicable to the path. A pixel is considered by the rendering engine 108 to be inside the shape if the centre of the pixel is 20 inside the shape.

Fig. 11 gives an example shape (a triangle) showing the pixel centres over the image and shading those pixels which are considered to be inside the shape. It will be appreciated that the pixel centres lie at half scanlines. The rendering engine 108 therefore samples edge crossings at half scanlines only. Several observations can thus be made.

.i Firstly, edge descriptions supplied by the path converter 210 must be such that generated edge crossings at half scanlines result in the correct coordinates, otherwise, incorrect pixels will be activated. A description of how this can be achieved will be found below.

551271.doc Secondly, in order to allow the rendering engine 108 to process path data efficiently, path edges need to be broken into monotonically increasing/decreasing edges. Each such monotonic edge then defines a direction (up or down), a starting scanline, a starting xposition, and a series of segments describing its x-positions on subsequent scanlines. The breaking of path edges into monotonic edges is a task well known in the art and need not be discussed further in this document. These monotonic edges are then presented to the rendering engine 108 in sorted order. The sorting of the monotonic edges is founded upon the starting y coordinate, and with the starting x coordinate as a minor sort criteria.

Below are the monotonic edges for the example path specified above and shown in Fig 4A.

monotonic edges: edge mo: start_x 100.0, start_y 100.5, direction down segments: step, x_offset 0, #scanlines 100 edge mi: start_x 200.0, start_y 100.5, direction up segments: step, x_offset 0, #scanlines 100 S:o; edge m2: start x 140.0, start y 140.5, direction up segments: step, x_offset=0, #scanlines Sedge m 3 start, x 160.0, start y 140.5, direction down .segments: step, x_offset 0, #scanlines The rendering engine 108 maintains a list of active monotonic edges for the current scanline of processing. Each monotonic edge has a current x-value, which the rendering engine 108 updates for each scanline. The active edge list will typically be maintained in sorted order by the rendering engine 108. Having described the workings of a rendering engine 108, the formation of the data 212 may be described in detail.

'i 25 Figs. 5A, 5E and 5H illustrate the three types of segments 502, 504 and 506 respectively defined herein for the purpose of updating the current x-value of a monotonic edge on a per scanline basis. The segments may be defined by at least one of the formats 551271.doc -6shown in Figs. 5B, 5C, 5D, 5F, 5G and 51. Each such segment format specifies a number of scanlines (ny) 524 for which each segment is effective, and an adjustment to the x-coordinate 522 to be made at each scanline. An ny value of 0 indicates that the segment produces pixels on one scanline only, ny=l produces pixels on two scanlines and so forth. Once the current segment expires, a new segment is loaded. An exception to this is a "FINISH" segment, shown in Fig. 5J, which marks the termination of the monotonic edge.

There are two types of segments to describe the x-adjustment the rendering engine 108 needs to make to the monotonic edge per scanline. The first such segment is a step-type segment 502 shown in Fig. 5A specifies a one-off adjustment to the current x-value to be made when the segment is loaded. The rendering engine 108 first adds the specified x-value before using the resulting value as the edge crossing for the current scanline. Three different formats are presented in Figs. 5B, 5C and 5D for the step segment, these being one, two and four byte formats as follows: 15 1-byte: x: 4bits[-8...7] 9ny: 3 bits, (represented as 2-byte: x: 7 bits, ny: 6 bits, 4-byte: x: 15 bits, [-16384...16393] 20 ny: 12 bits, [1...4046] A second such segment is a vector type segment shown in Fig. 5E specifies a slope (dx) value 526 to be applied to the current x-value after the segment has produced an edge crossing for the current scanline. Two formats of vector segments are shown in Figs. 5F and 5G, those being a three byte, and a five byte format respectively, represented as follows: 3-byte: dx: 7.6 fixed point number, range -64.0...63.98 551271.doc -7ny: 6 bits, dx: 12.14 fixed point number range -2048.0.. .2047.99994 ny: 11 bits, [1...2048] A further type of segment is a step-vector segment 506 is shown in Fig. which may be defined by the format of Fig. 51 having a 7-byte structure in which: x: 8.8 fixed point, range -128.0...127.992 dx: 11.14 fixed point, range -1024.0...1024.99994 ny: 9 bits, [1...512] The FINISH segment 508 has a 1-byte format shown in Fig. Fig. 7 illustrates the scanlines influenced by arbitrary segments 700 and 702.

The first segment 700 affects the half scanlines at scanlines y=l and y=2, but expires at scanline y=3. The second segment 702 is loaded, taking effect on scanline y=3, and also affecting scanlines y=4 and 15 The rendering engine 108 recognizes the type of segment being used using the o bit stream encoded at the start of the segment. In order to achieve the goal of minimizing the storage requirements for its binary output, the path converter 210 uses the smallest available segment format possible to satisfy the edge description. Before describing an algorithm used to achieve such minimization, it is appropriate to discuss a previously made observation the need to produce correct edge crossings at half scanlines.

Path data arrives at the path converter 210 as pairs of floating point (x,y) coordinates for each path edge. The monotonic edge segments that must be produced, however, must both begin and end on half scanline boundaries. With reference to Fig. 7, given a straight line segment 700, the path converter 210 first calculates the value of dx for that segment. The starting x-coordinate 706 of the segment is then determined, this being the intersection of the segment 700 with the next half scanline down the page from 551271.doc -8 the corresponding actual starting point 704. Should the point actually lie on a half scanline, no calculation is required. Similarly, the ending x-coordinate 708 on the half scanline following the actual specified end point is calculated. The segment then is responsible for the generation of edge crossings from the calculated starting half scanline to, but not including, the calculated ending half scanline.

Fig. 8 shows a monotonic edge with two segments 802 and 804 described by a format (eg. floating point) that has a higher resolution than that of a display upon which the image is to be reproduced. The top segment 802, being a vector, commences at a point 801 and ends at a point 803 which, as seen, is not located centrally within the display pixel, having a pixel centre 812. The bottom segment 804 in its high resolution format similarly commences at the point 803 and ends at a point 805. In this discussion, an appropriate handling of the change of direction of the segments 802 and 804 at the point 803 for the purposes of lower resolution display is required. This is achieved by projecting the segment 802 to a certain crossing 806 at a half scanline 808, which in one axis is centrally located within the pixel. Similarly, the corresponding desired crossing for the segment 804 lies at the intersection of the half scanline 808, and thus a new "start" to the segment 804 is created at a crossing 810. As the two crossings 806 and 810 lie on differing sides of the pixel centre 812, it necessary that the correct crossing be interpreted by the rendering engine 108. Such is ensured by making the bottom segment 804 a seven-byte format step-vector segment. When encountering this segment 804 on the half scanline, the rendering engine 108 first adds to the current x-position of the edge the xoffset field specified in the segment. The x-offset in this regard is seen in Fig. 8 as an adjustment 814. This forces an adjustment to be made to generate the correct crossing at that half scanline 808. In this regard, at any one scanline, only one segment can have an effect for any vectorized path. The same also applies to half-scanlines and in the 551271.doc -9preferred formats being described the top segment, such as the segment 802 in Fig. 8 is forced to have no effect at that half-scanline. As such, the bottom segment 804 starts at the edge crossing 810 on the half-scanline 808, and the segment 802 is forced to terminate at an edge crossing 816 on the preceding half-scanline. The rendering engine 108 then continues to follow the seven-byte segment in a manner corresponding to an ordinary vector segment, applying the dx field after each crossing is generated.

Having described the binary output format of the path converter 210 and the half-scanline adjustment problems desired to be addressed, a process 600 used to binarize a vectorized path is shown in Fig. 6, which in turn references Figs. 9 and An example of the operation of the path converter 210 according to the process 600 in Fig. 6 is presented in Fig. 12, having a path object defined by: path: 1 edge edge: 5 points 100.0, 100.5 15 50.0,200.0 75.0,300.0 S'100.0, 250.5 S100.0, 100.5 In the process 600, appropriate pointers are initialized at step 604 and edges 20 collected at step 606. Step 610 initializes current x,y coordinates which are set to the start of a first edge (100.0, 100.5), and pointers are initialized to point to the first monotonic edge, being the downward heading component from point (100.0, 100.5) to the point (75.0, 300.0). At step 614, the x_offset is initialized to 0, and is then calculated in step 618. Step 620 checks x_offset, which in this case is found to be 0 (since the starting point already lies on the half scanline) and implements step 626, being the flow chart in Fig. 10. The process 626 of Fig. 10 then generates a 5-byte vector for the segment 551271.doc (100.0, 100.5) to (50.0, 200.0) of Fig. 12. Fig. 6 then calculates the current x-position at the half scanline location y 200.5: (dx=(50.0-100.0) (200.0-100.5) -0.5025.

Therefore: x 50.0 dx (200.5-200.0) 49.75.

Since there are more points, as determined at step 616, step 618 works out the x_offset from where it is desired to be on the half scanline (derived from the slope of the next segment (50.0, 200.0) to (75.0, 300.0)). This results in a non-zero value and step 624 refers to the flow chart of Fig. 9 which is then executed, resulting in the generation of a 7-byte segment. Since no more points are present in the current monotonic edge as determined by step 616, the edge is terminated with a FINISH segment. Control returns via step 612 to step 614 to look for the next monotonic component. Step 614 locates the (75.0, 300.0) to (100.0, 100.5) upward heading component, and establishes the pointers to process the component from top to bottom, setting the xoffset to 0. The segment from (100.0, 100.5) to (100.0, 250.5) is then processed by step 626 (Fig. 10), resulting in the generation of a 4-byte step segment at step 622. Next, via steps 616, 612 and 614, the (100.0, 250.5) to (75.0, 300.0) segment is examined. Since the starting point is already on the half scanline, the current x becomes 100.0 and the x_offset remains at zero, as determined by steps 618 and 620 (Fig. 10). Step 626 is then invoked, producing a 3-byte vector for the edge. Since there are no more points, the edge is then terminated with a o FINISH segment, and the processing of the path 1200 completes. The resulting output comprises edge data having segment data component of the form: edge: start x=100.0, start y 100.5, direction down segment: 5 byte vector: dx -0.5025 ny 99 segment: 7 byte step-vector: x offset 0.375 551271.doc -iidx 0.25 ny 99 segment: FINISH edge start x 100.0, start y 100.5, direction up segment: 4 byte step: x offset 0 ny 149 segment: 3 byte vector: dx ny 49 segment: FINISH Step 626 shown in Fig. 10 operates initially at step 688 to determine whether dx or ny equals 0 and if such is the case, step 690 creates a step segment concluding at step 698. Where either dx or ny have a non-zero value, the remaining process steps essentially assess the size of dx to determine the number of bytes required to define an appropriate vector segment. Where step 692 determines that dx fits into a 5-byte vector, 15 step 695 is implemented. This is a most common situation. Where step 692 determines a dx is too large for a 5-byte vector, step 693 determines whether or not dx is sufficient for a 4-byte step segment. If so, step 694 creates such a segment, for each scanline, stepping the vector down line-by-line. If not, a new edge for each line is created at step 696.

These processes conclude at step 698.

Where the value ofx_offset is not equal to 0 as determined at step 620, step 624, shown in Fig. 9, is implemented. Step 624 operates on the principle of using smaller sized segments where possible. Like Fig. 10, where the slope of segment is larger than can be represented using described binary formats of Figs. 5B to 51, the process steps of 624 attempt to create step segments per scanline so as to step the edge downwards across the display. If the slope is too large for even a step segment, a new edge is created for each such scanline.

551271.doc -12- Within the processing of Figs. 9 and 10, a number of sub-routines are called, those sub-routines being named mfet_seg_step_smi mfet_seg_vec_smi and mfet_seg_vec_offset_smi. The subroutine mfet_seg_step_smi, called at steps 636, 648, 652, 666, 678, 684, 690 and 694, acts to add a step segment of Fig. 5A to the current edge. A selection is made from one of the formats of Figs. 5B to 5D depending on the size of the step required. The subroutine mfet_seg_vec_ smi called at steps 658, 670, and 695, acts to add a vector segment of Fig. 5E to the current edge. A selection is made from one of the formats of Figs. 5F and 5G depending on the size of the vector required.

Depending on the length of the vector, such a segment may be described using a combination of the formats of Figs. 5F and 5G. The subroutine mfet_seg_vec_offset_smi, called at steps 644 and 654, acts to add a step-vector segment of Fig. 5H to the current edge. The format of Fig. 51 is used.

The arrangements described above provide for the generation of multi-format edge segments that are used to describe a traditional vectorized path in which the multi- 15 format arrangement provides for a substantial reduction in the storage requirements of edge segment data generated by a path converter. Such an arrangement is advantageous in that it provides for optimised storage of information ready to be input to a rendering engine 108 for the generation of a pixel image. Significantly, the use of an offset combined with a slope value for the segment provides within the level of accuracy of the system that the correct crossing is generated at each half scanline. These arrangements also provide for an efficient method of converting a vectorized path into a compact binary format suitable for rendering at high speeds using known rendering arrangements.

The conversion methods described above are preferably practiced using a conventional general-purpose computer system 1300, such as that shown in Fig. 13 wherein the processes of Figs. 6, 9 and 10 may be implemented as program code or 551271.doc -13software, such as an application program executing within the computer system 1300. In particular, the steps of conversion method are effected by instructions in the software that are carried out by the computer. The software may be divided into two separate parts; one part for carrying out the conversion methods; and another part to manage any user interface between the latter and the user. The software may be stored in a computer readable medium, including the storage devices described below, for example. The software is loaded into the computer from the computer readable medium, and then executed by the computer. A computer readable medium having such software or computer program recorded on it is a computer program product. The use of the computer program product in the computer preferably effects an advantageous apparatus for converting vectorized path into a renderable format in accordance with the embodiments of the invention.

The computer system 1300 comprises a computer module 1301, input devices such as a keyboard 1302 and mouse 1303, output devices including a printer 1315 and a 15 display device 1314. A Modulator-Demodulator (Modem) transceiver device 1316 is used by the computer module 1301 for communicating to and from a communications .oo..i network 1320, for example connectable via a telephone line 1321 or other functional medium. The modem 1316 can be used to obtain access to the Internet, and other network systems, such as a Local Area Network (LAN) or a Wide Area Network (WAN).

The computer module 1301 typically includes at least one processor unit 1305, a 4.

memory unit 1306, for example formed from semiconductor random access memory (RAM) and read only memory (ROM), input/output interfaces including a video interface 1307, and an I/O interface 1313 for the keyboard 1302 and mouse 1303 and optionally a joystick (not illustrated), and an interface 1308 for the modem 1316. A storage device 1309 is provided and typically includes a hard disk drive 1310 and a 551271.doc -14floppy disk drive 1311. A magnetic tape drive (not illustrated) may also be used. A CD- ROM drive 1313 is typically provided as a non-volatile source of data. The components 1305 to 1313 of the computer module 1301, typically communicate via an interconnected bus 1304 and in a manner which results in a conventional mode of operation of the computer system 1300 known to those in the relevant art. Examples of computers on which the arrangements described can be practised include IBM-PC's and compatibles, Sun Sparcstations or alike computer systems evolved therefrom.

Typically, the application program is resident on the hard disk drive 1310 and read and controlled in its execution by the processor 1305. Intermediate storage of the program and any image or object data fetched from the network 1320 may be accomplished using the semiconductor memory 1306, possibly in concert with the hard disk drive 1310. In some instances, the application program may be supplied to the user encoded on a CD-ROM or floppy disk and read via the corresponding drive 1313 or 1311, or alternatively may be read by the user from the network 1320 via the modem device 1316. Still further, the software can also be loaded into the computer system 1300 from other computer readable medium including magnetic tape, a ROM or integrated circuit, a magneto-optical disk, a radio or infra-red transmission channel between the computer module 1301 and another device, a computer readable card such as a PCMCIA card, and the Internet and Intranets including e-mail transmissions and information 20 recorded on Websites and the like. The foregoing is merely exemplary of relevant °•oo• :computer readable media. Other computer readable mediums may be practiced without departing from the scope and spirit of the invention.

In this fashion, the computer system 1300 may be used to generate graphic object shapes, which may be vectorized and, using the embodiment described herein, produce edge and segment data for use by a rendering engine that is optimised for size 551271.doc and yet enables fast rendering. Such optimisation is desirable since it is often required to store such edge and segment data whilst building an image that is to be rendered at some later time.

Industrial Applicability It is apparent from the above that the disclosure is applicable to the computer graphics industry.

The foregoing describes only one embodiment/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 embodiment 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 corresponding meanings.

r.

a ao a a r 551271.doc

Claims (2)

16- THE CLAIMS DEFINING THE INVENTION ARE AS FOLLOWS: I. A method of converting data defining a vectorized path into a renderable format, said method comprising the steps of: identifying adjacent pairs of points within said path; for each said pair of points, forming a straight line segment using a vectorized data format; and forming a renderable data format for each said segment by modifying said vectorized data format for at least one said segment, said modifying comprising compensating for a scanline error between adjacent ones of said segments when a change of direction occurs between two adjacent ones of said segments. 2. A method according to claim 1, wherein said modifying compensates for a half- scanline error between said adjacent segments. 3. A method according to claim 1 or 2, wherein step comprises determining at least a number of scanlines for which each said segment is effective. 4. A method according to claim 3, wherein step further comprises determining whether said segment is one of monotonic increasing or decreasing and if so, calculating a change in pixel value valid for said number of scanlines and determining a terminal point "on a final scanline for said segment, said final scanline being a first scanline of said adjacent segment having a first point, the difference between said terminal point and said first point defining a pixel offset value to be used for said compensating.

551271.doc 17- A method according to claim 4, wherein said renderable data format comprises a plurality of segment description types and sizes, and step further comprises determining a minimum description size by which the number of scanlines, the change in pixel value, and the pixel offset value for each said segment are represented. 6. A method according to any one of the preceding claims, wherein step (c) comprises converting a floating point description of said segment and said points to a description relating to a renderable number of scanlines and to a number of pixel locations on each said scanline. 7. Apparatus for converting data defining a vectorized path into a renderable format, said apparatus comprising identification means for identifying adjacent pairs of points within said path; forming means for forming a straight line segment using a vectorized data format for each said pair of points; and formatting means for forming a renderable data format for each said segment by modifying said vectorized data format for at least one said segment, said formatting means being operable to compensate for a scanline error between adjacent ones of said segments when a change of direction occurs between two adjacent ones of said segments. 8. Apparatus according to claim 7, wherein said formatting means compensates for .ee S"a half-scanline error between said adjacent segments. a ooo 551271.doc i8 9. Apparatus according to claim 7 or 8, wherein said formatting means is operable to determine at least a number of scanlines for which each said segment is effective. Apparatus according to claim 9, wherein said formatting means further comprises means for determining whether said segment is one of monotonic increasing or decreasing and if so, calculating a change in pixel value valid for said number of scanlines and determining a terminal point on a final scanline for said segment, said final scanline being a first scanline of said adjacent segment having a first point, the difference between said terminal point and said first point defining a pixel offset value to be used for said compensating. 11. Apparatus according to claim 10, wherein said renderable data format comprises a plurality of segment description types and sizes, and formatting means further comprises means for determining a minimum description size by which the number of scanlines, the change in pixel value and the pixel offset value for each said segment are 15 represented. 9* 9 12. Apparatus according to any one of claims 7 to 11, wherein said formatting means further comprises means for converting a floating point description of said segment and said points to a description relating to a renderable number of scanlines and to a number of pixel locations on each said scanline. 13. Apparatus according to any one of claims 7 to 12, said apparatus being formed by a computing device and said means being formed in part by software executable within said computing device. 551271.doc -19- 14. A computer program for converting data defining a vectorized path into a renderable format, said computer program comprising: code for identifying adjacent pairs of points within said path; code for forming a straight line segment using a vectorized data format for each said pair of points; and code for forming a renderable data format for each said segment by modifying said vectorized data format for at least one said segment, said modifying comprising compensating for a scanline error between adjacent ones of said segments when a change of direction occurs between two adj acent ones of said segments. A computer program according to claim 14, wherein said modifying compensates for a half-scanline error between said adjacent segments. 16. A computer program according to claim 14 or 15, wherein said code for forming said renderable data format comprises code for determining at least a number of scanlines *for which each said segment is effective. 17. A computer program according to claim 16, wherein said code for forming said renderable data format comprises code for determining whether said segment is one of monotonic increasing or decreasing and if so, calculating a change in pixel value valid for said number of scanlines and determining a terminal point on a final scanline for said ool segment, said final scanline being a first scanline of said adjacent segment having a first point, the difference between said terminal point and said first point defining a pixel a offset value to be used for said compensating. 551271.doc 18. A computer program according to claim 17, wherein said renderable data format comprises a plurality of segment description types and sizes, and said code for forming said renderable data format further comprises code for determining a minimum description size by which the number of scanlines, the change in pixel value, and the pixel offset value for each said segment are represented. 19. A computer program according to any one of claims 14 to 18, wherein said code for forming said renderable data format comprises code for converting a floating point description of said segment and said points to a description relating to a renderable number of scanlines and to a number of pixel locations on each said scanline. A computer readable medium comprising a computer program according to any one of claims 14 to 19. 21. A method of converting data defining a vectorized path into a renderable format, said method being substantially as described herein with reference to Figs. 5A to 10 of the drawings. 22. Apparatus for converting data defining a vectorized path into a renderable format, said apparatus being substantially as described herein with reference to Figs. to 10 and 13 of the drawings. *eo• oee 551271.doc 21 23. A computer program for converting data defining a vectorized path into a renderable format, said program being substantially as described herein with reference to Figs. 5A to 10 of the drawings. 24. A rendering system including an arrangement for converting data defining a vectorized path into a renderable format, said system being substantially as described herein with reference to the drawings. Dated this TWENTY-SEVENTH day of APRIL 2001 CANON KABUSHIKI KAISHA Patent Attorney for the Applicant Spruson&Ferguson o0 O *too S S S 00 S SO 551271.doc