AU2012202491A1 - Method, system and apparatus for rendering an image on a page - Google Patents

Abstract

Abstract METHOD, SYSTEM AND APPARATUS FOR RENDERING AN IMAGE ON A A method of rendering an object on a page defined by a personalised print markup language (PPML), using a pixel-sequential renderer (300), is disclosed. The object to be rendered is received, the object indicating if the object is to be rendered using a PPML 2.2 standard "Paint-As-Opaque" rendering operation or a PPML 3.0 standard "Strict-Paint-As [0 Opaque" rendering operation. An opacity value of a pixel of the object on the page is determined. The object is rendered using the rendering operation indicated by the object. For the PPML 2.2 standard "Paint-As-Opaque" rendering operation, the pixel-sequential renderer (300) renders the pixel with an opaque white background in an event that the determined opacity is greater than zero. For the PPML 3.0 standard "Strict-Paint-As-Opaque" rendering 15 operation, the pixel-sequential renderer (300) renders the pixel with an opaque white background in an event that the determined opacity value is greater than or equal to zero. P032236_SpeciAs Filed 6241977v]

Description

S&F Ref: P032236 AUSTRALIA PATENTS ACT 1990 COMPLETE SPECIFICATION FOR A STANDARD PATENT Name and Address Canon Kabushiki Kaisha, of 30-2, Shimomaruko 3 of Applicant: chome, Ohta-ku, Tokyo, 146, Japan Actual Inventor(s): Giles Anderson Puckett Address for Service: Spruson & Ferguson St Martins Tower Level 35 31 Market Street Sydney NSW 2000 (CCN 3710000177) Invention Title: Method, system and apparatus for rendering an image on a page The following statement is a full description of this invention, including the best method of performing it known to me/us: 5845c(6242337_1) -1 METHOD, SYSTEM AND APPARATUS FOR RENDERING AN IMAGE ON A PAGE FIELD OF INVENTION The current invention relates to computer graphics and, in particular, to a method for rendering graphical objects specified in mark-up languages having opposing transparency 5 requirements. The current invention also relates to a computer program product including a computer readable medium having recorded thereon a computer program for rendering graphical objects specified in mark-up languages having opposing transparency requirements. DESCRIPTION OF BACKGROUND ART Mark-up languages, as used in computer graphics and document processing, enable a 0 combination of graphical content data from different sources to be printed into a single document. Such different sources of graphical content data often have different transparency processing requirements depending upon a page description language (PDL) in which the graphical content data is specified. As an example of different transparency processing requirements, mark-up languages can 5 differ in their definitions of which points are marked by source data expressed in PDLs. For example, the Personalized Print Mark-up Language (PPML) 2.2 specification defines a marked point as a point having an associated alpha value which is non-zero. PPML 2.2 also defines that all marked points are regarded as opaque with a colour value derived from source data rendered directly onto the underlying medium. Such a definition causes source data with £0 fully transparent objects (such as in portable document format (PDF) 1.4 and later content) to allow content from objects below to be visible. However, the PPML 3.0 specification omits the requirement that the alpha value of a marked point be non-zero, so that a fully transparent point in the source data is still considered to mark the point. The PPML 3.0 specification also allows source data to be processed according to PDF transparency processing, so that 25 overlapping sources may composite with one another. The PPML 3.0 specification states that: "If Transparency="None", then the content defined by the rendering of source data shall always have an alpha value of zero (0) or one (1)". In PPML 3.0, marked points shall have an alpha value of one (1). Each marked point shall have a colour which approximates a rendition of the source data directly onto the underlying 30 medium. All unmarked points shall have an alpha value of zero (0). P032236_SpeciAs Filed 6241977v] -2 In PPML 2.2, a fully transparent point defined by an image operator is considered unmarked. In PPML 3.0, such a fully transparent point is considered marked and has an alpha value of one (1) so as to be consistent with standard transparency flattening behaviour for PDF. 5 The PPML 3.0 specification also states that: "If Transparency="Isolated", then the content defined by rendering of corresponding source data may have alpha values between zero (0) and one (I) inclusive. In PPML 3.0, the alpha value shall be set as if the content was rendered as an isolated transparency group (as defined in the PDF specification)". In addition to the different transparency requirements of PDLs providing content, the mark 0 up language itself can impose different transparency requirements. The mark-up language may require additional RIPs to process the output of the existing PDLs, with attendant performance penalties from multiple handling of large amounts of pixel data, whether or not the pixel data actually requires transparency processing. Thus, a need exists for a single RIP which can support conflicting transparency processing 5 requirements of a large number of mark-up languages and PDLs in a highly efficient manner. 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. Disclosed are arrangements which seek to address the above problems by providing high .0 performance flexibility in RIP implementations. The disclosed arrangements may dynamically select at runtime rendering rules of either PPML 2.2 defining a "Paint-As Opaque" rendering operation, or PPML 3.0 defining a "Strict-Paint-As-Opaque" rendering operation. The disclosed arrangements may also select the standard transparency rules required by PDF and other page description languages. 25 The disclosed arrangements do not affect performance of rendering other parts of a document, such as data within PPML content itself. In the disclosed arrangements, transparency processing is carried out as required. According to one aspect of the present disclosure, there is provided a method of rendering an object on a page defined by a personalised print markup language (PPML), using a pixel 30 sequential renderer, said method comprising: P032236_SpeciAs Filed 6241977vl -3 receiving the object to be rendered, said object indicating if the object is to be rendered using a PPML 2.2 standard "Paint-As-Opaque" rendering operation or a PPML 3.0 standard "Strict-Paint-As-Opaque" rendering operation; determining an opacity value of a pixel of the object on the page; and 5 rendering the object using the rendering operation indicated by said object, wherein for said PPML 2.2 standard "Paint-As-Opaque" rendering operation, said pixel-sequential renderer renders said pixel with an opaque white background in an event that the determined opacity is greater than zero, and wherein for said PPML 3.0 standard "Strict-Paint-As Opaque" rendering operation, said pixel-sequential renderer renders said pixel with an opaque 0 white background in an event that the determined opacity value is greater than or equal to zero. According to another aspect of the present disclosure, there is provided an apparatus for rendering an object on a page defined by a personalised print markup language (PPML), using a pixel-sequential renderer, said apparatus comprising: 5 means for receiving the object to be rendered, said object indicating if the object is to be rendered using a PPML 2.2 standard "Paint-As-Opaque" rendering operation or a PPML 3.0 standard "Strict-Paint-As-Opaque" rendering operation; means for determining an opacity value of a pixel of the object on the page; and means for rendering the object using the rendering operation indicated by said object, .0 wherein for said PPML 2.2 standard "Paint-As-Opaque" rendering operation, said pixel sequential renderer renders said pixel with an opaque white background in an event that the determined opacity is greater than zero, and wherein for said PPML 3.0 standard "Strict-Paint As-Opaque" rendering operation, said pixel-sequential renderer renders said pixel with an opaque white background in an event that the determined opacity value is greater than or 25 equal to zero. According to still another aspect of the present disclosure, there is provided a system for rendering an object on a page defined by a personalised print markup language (PPML), using a pixel-sequential renderer, said system comprising: a memory for storing data and a computer program; 30 a processor coupled to said memory for executing said computer program, said computer program comprising instructions for: P032236_SpeciAs Filed 6241977vl -4 receiving the object to be rendered, said object indicating if the object is to be rendered using a PPML 2.2 standard "Paint-As-Opaque" rendering operation or a PPML 3.0 standard "Strict-Paint-As-Opaque" rendering operation; determining an opacity value of a pixel of the object on the page; and 5 rendering the object using the rendering operation indicated by said object, wherein for said PPML 2.2 standard "Paint-As-Opaque" rendering operation, said pixel-sequential renderer renders said pixel with an opaque white background in an event that the determined opacity is greater than zero, and wherein for said PPML 3.0 standard "Strict-Paint-As -Opaque" rendering operation, said pixel-sequential renderer 0 renders said pixel with an opaque white background in an event that the determined opacity value is greater than or equal to zero. According to still another aspect of the present disclosure, there is provided a computer readable medium having a computer program recorded there for rendering an object on a page defined by a personalised print markup language (PPML), using a pixel-sequential renderer, 5 said program comprising: code for receiving the object to be rendered, said object indicating if the object is to be rendered using a PPML 2.2 standard "Paint-As-Opaque" rendering operation or a PPML 3.0 standard "Strict-Paint-As-Opaque" rendering operation; code for determining an opacity value of a pixel of the object on the page; and :0 code for rendering the object using the rendering operation indicated by said object, wherein for said PPML 2.2 standard "Paint-As-Opaque" rendering operation, said pixel sequential renderer renders said pixel with an opaque white background in an event that the determined opacity is greater than zero, and wherein for said PPML 3.0 standard "Strict-Paint As-Opaque" rendering operation, said pixel-sequential renderer renders said pixel with an 25 opaque white background in an event that the determined opacity value is greater than or equal to zero. Other aspects of the invention are also disclosed. BRIEF DESCRIPTION OF THE DRAWINGS One or more embodiments of the invention will now be described with reference to the 30 following drawings, in which: Fig. I shows compositing operations performed on a group of objects by a pixel sequential renderer; P032236_SpeciAs Filed 6241977v1 -5 Fig. 2 shows compositing operations, including a transparency flattening operation, performed on a group of objects by a pixel sequential renderer; Fig. 3 shows a pixel sequential renderer; Figs. 4A and 4B shows a compositing list and compositing stack when evaluating 5 compositing lists from an isolated group of objects; Figs. 4C and 4D show a compositing list and compositing stack when evaluating compositing lists from an isolated group with transparency flattening; Figs. 5A and 5B form a schematic block diagram of a general purpose computer system upon which arrangements described can be practiced; and 0 Fig. 6 is a flow diagram showing a method of rendering an object on a page using the method disclosed in the current invention. DETAILED DESCRIPTION OF EMBODIMENTS OF THE INVENTION 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 5 purposes of this description the same function(s) or operation(s), unless the contrary intention appears. A pixel-sequential renderer 300 (see Fig. 3) supporting both PPML 2.2 documents and PPML 3.0 documents is disclosed below. The renderer 300 supports both definitions of a marked point, in addition to the standard transparency compositing requirements defined in 0 page description languages such as PDF. The renderer 300 is an example of a raster image processor (RIP). All printing systems have a need for a raster image processor (RIP). RIPs may be implemented as software and/or hardware according to requirements of various markup languages and PDLs that are supported. RIPs combine graphical content onto pages and produce display lists or rasterised 25 data for printing. In an RIP supporting multiple markup languages or PDLs, there may be conflicting requirements in the definition of transparency processing. In such cases, multiple RIPs may be configured within a single printing system, with each RIP supporting a specific subset of markup or PDL languages. However, such printing systems are often inefficient as there is overhead in determining which RIP is required for each print job. Further, such 30 printing systems are also not cost effective as the printing system requires storage for at least two RIPs and sufficient memory and processing resources for the least efficient RIP. Still further, other differences in output may be apparent in such multiple RIP printing systems P032236_SpeciAs Filed 6241977vl -6 because of anomalies in various RIPs. In addition, a manufacturer of such a printing system must thoroughly test each RIP, leading to increased development, validation and verification costs and consequently increased product cost. The Personalised Print Markup Language (PPML) is an XML based variable data printing 5 language that allows existing graphical content in any page description language (PDL), or source data, to be flexibly reused as a graphical object within a variable data print job. Each of the page description languages may have their own transparency processing rules. Further, content from various page description language files may overlap and composite with each other. 0 Figs. 5A and 5B depict a general-purpose computer system 500, upon which the various one of the arrangements described can be practiced. As seen in Fig. 5A, the computer system 500 includes: a computer module 501; input devices such as a keyboard 502, a mouse pointer device 503, a scanner 526, a camera 527, and a microphone 580; and output devices including a printer 515, a display device 514 and 5 loudspeakers 517. An external Modulator-Demodulator (Modem) transceiver device 516 may be used by the computer module 501 for communicating to and from a communications network 520 via a connection 521. The communications network 520 may be a wide-area network (WAN), such as the Internet, a cellular telecommunications network, or a private WAN. Where the connection 521 is a telephone line, the modem 516 may be a traditional 0 "dial-up" modem. Alternatively, where the connection 521 is a high capacity (e.g., cable) connection, the modem 516 may be a broadband modem. A wireless modem may also be used for wireless connection to the communications network 520. The computer module 501 typically includes at least one processor unit 505, and a memory unit 506. For example, the memory unit 506 may have semiconductor random access memory 25 (RAM) and semiconductor read only memory (ROM). The computer module 501 also includes an number of input/output (I/O) interfaces including: an audio-video interface 507 that couples to the video display 514, loudspeakers 517 and microphone 580; an I/O interface 513 that couples to the keyboard 502, mouse 503, scanner 526, camera 527 and optionally a joystick or other human interface device (not illustrated); and an interface 508 for 30 the external modem 516 and printer 515. In some implementations, the modem 516 may be incorporated within the computer module 501, for example within the interface 508. The computer module 501 also has a local network interface 511, which permits coupling of the PO32236_Speci_As Filed 6241977v] -7 computer system 500 via a connection 523 to a local-area communications network 522, known as a Local Area Network (LAN). As illustrated in Fig. 5A, the local communications network 522 may also couple to the wide network 520 via a connection 524, which would typically include a so-called "firewall" device or device of similar functionality. The local 5 network interface 511 may comprise an Ethernet"m circuit card, a BluetoothTM wireless arrangement or an IEEE 802.11 wireless arrangement; however, numerous other types of interfaces may be practiced for the interface 511. The I/O interfaces 508 and 513 may afford either or both of serial and parallel connectivity, the former typically being implemented according to the Universal Serial Bus (USB) 0 standards and having corresponding USB connectors (not illustrated). Storage devices 509 are provided and typically include a hard disk drive (HDD) 510. Other storage devices such as a floppy disk drive and a magnetic tape drive (not illustrated) may also be used. An optical disk drive 512 is typically provided to act as a non-volatile source of data. Portable memory devices, such optical disks (e.g., CD-ROM, DVD, Blu-ray Disc TM), USB-RAM, portable, 5 external hard drives, and floppy disks, for example, may be used as appropriate sources of data to the system 500. The components 505 to 513 of the computer module 501 typically communicate via an interconnected bus 504 and in a manner that results in a conventional mode of operation of the computer system 500 known to those in the relevant art. For example, the processor 505 is 0 coupled to the system bus 504 using a connection 518. Likewise, the memory 506 and optical disk drive 512 are coupled to the system bus 504 by connections 519. Examples of computers on which the described arrangements can be practised include IBM-PC's and compatibles, Sun Sparcstations, Apple MacTM or a like computer systems. Methods described below may be implemented using the computer system 500 wherein 25 processes described with reference to Figs. 1 to 4 and Fig. 6, may be implemented as one or more software application programs 533 executable within the computer system 500. In particular, the steps of the described methods may be effected by instructions 531 (see Fig. 5B) in the software 533 that are carried out within the computer system 500. The software instructions 531 may be formed as one or more code modules, each for performing 30 one or more particular tasks. The software may also be divided into two separate parts, in which a first part and the corresponding code modules performs the described methods and a P032236_SpeciAs Filed 6241977vl -8 second part and the corresponding code modules manage a user interface between the first part and the user. The software may be stored in a computer readable medium, including the storage devices described below, for example. The software 533 is typically stored in the HDD 510 or the 5 memory 506. The software is loaded into the computer system 500 from the computer readable medium, and then executed by the computer system 500. Thus, for example, the software 533 may be stored on an optically readable disk storage medium (e.g., CD ROM) 525 that is read by the optical disk drive 512. A computer readable medium having such software or computer program recorded on the computer readable medium is a computer 0 program product. The use of the computer program product in the computer system 500 preferably effects an advantageous apparatus for implementing the described methods. In some instances, the application programs 533 may be supplied to the user encoded on one or more CD-ROMs 525 and read via the corresponding drive 512, or alternatively may be read by the user from the networks 520 or 522. Still further, the software can also be loaded 5 into the computer system 500 from other computer readable media. Computer readable storage media refers to any non-transitory tangible storage medium that provides recorded instructions and/or data to the computer system 500 for execution and/or processing. Examples of such storage media include floppy disks, magnetic tape, CD-ROM, DVD, Blu TM ray Disc, a hard disk drive, a ROM or integrated circuit, USB memory, a magneto-optical .0 disk, or a computer readable card such as a PCMCIA card and the like, whether or not such devices are internal or external of the computer module 501. Examples of transitory or non tangible computer readable transmission media that may also participate in the provision of software, application programs, instructions and/or data to the computer module 501 include radio or infra-red transmission channels as well as a network connection to another computer 25 or networked device, and the Internet or Intranets including e-mail transmissions and information recorded on Websites and the like. The second part of the application programs 533 and the corresponding code modules mentioned above may be executed to implement one or more graphical user interfaces (GUls) to be rendered or otherwise represented upon the display 514. Through manipulation of 30 typically the keyboard 502 and the mouse 503, a user of the computer system 500 and the application may manipulate the interface in a functionally adaptable manner to provide controlling commands and/or input to the applications associated with the GUI(s). Other P032236_SpeciAs Filed 6241977vl -9 forms of functionally adaptable user interfaces may also be implemented, such as an audio interface utilizing speech prompts output via the loudspeakers 517 and user voice commands input via the microphone 580. Fig. 5B is a detailed schematic block diagram of the processor 505 and a "memory" 534. 5 The memory 534 represents a logical aggregation of all the memory modules (including the HDD 509 and semiconductor memory 506) that can be accessed by the computer module 501 in Fig. 5A. When the computer module 501 is initially powered up, a power-on self-test (POST) program 550 executes. The POST program 550 is typically stored in a ROM 549 of the 0 semiconductor memory 506 of Fig. 5A. A hardware device such as the ROM 549 storing software is sometimes referred to as firmware. The POST program 550 examines hardware within the computer module 501 to ensure proper functioning and typically checks the processor 505, the memory 534 (509, 506), and a basic input-output systems software (BIOS) module 551, also typically stored in the ROM 549, for correct operation. Once the POST 5 program 550 has run successfully, the BIOS 551 activates the hard disk drive 510 of Fig. 5A. Activation of the hard disk drive 510 causes a bootstrap loader program 552 that is resident on the hard disk drive 510 to execute via the processor 505. This loads an operating system 553 into the RAM memory 506, upon which the operating system 553 commences operation. The operating system 553 is a system level application, executable by the processor 505, to fulfil 0 various high level functions, including processor management, memory management, device management, storage management, software application interface, and generic user interface. The operating system 553 manages the memory 534 (509, 506) to ensure that each process or application running on the computer module 501 has sufficient memory in which to execute without colliding with memory allocated to another process. Furthermore, the 25 different types of memory available in the system 500 of Fig. 5A need to be used properly so that each process can run effectively. Accordingly, the aggregated memory 534 is not intended to illustrate how particular segments of memory are allocated (unless otherwise stated), but rather to provide a general view of the memory accessible by the computer system 500 and how such is used. 30 As shown in Fig. 5B, the processor 505 includes a number of functional modules including a control unit 539, an arithmetic logic unit (ALU) 540, and a local or internal memory 548, sometimes called a cache memory. The cache memory 548 typically includes a number of P032236_Speci_As Filed 6241977vl - 10 storage registers 544 - 546 in a register section. One or more internal busses 541 functionally interconnect these functional modules. The processor 505 typically also has one or more interfaces 542 for communicating with external devices via the system bus 504, using a connection 518. The memory 534 is coupled to the bus 504 using a connection 519. 5 The application program 533 includes a sequence of instructions 531 that may include conditional branch and loop instructions. The program 533 may also include data 532 which is used in execution of the program 533. The instructions 53 1 and the data 532 are stored in memory locations 528, 529, 530 and 535, 536, 537, respectively. Depending upon the relative size of the instructions 531 and the memory locations 528-530, a particular instruction may be 0 stored in a single memory location as depicted by the instruction shown in the memory location 530. Alternately, an instruction may be segmented into a number of parts each of which is stored in a separate memory location, as depicted by the instruction segments shown in the memory locations 528 and 529. In general, the processor 505 is given a set of instructions which are executed therein. The 5 processor 1105 waits for a subsequent input, to which the processor 505 reacts to by executing another set of instructions. Each input may be provided from one or more of a number of sources, including data generated by one or more of the input devices 502, 503, data received from an external source across one of the networks 520, 502, data retrieved from one of the storage devices 506, 509 or data retrieved from a storage medium 525 inserted into the 0 corresponding reader 5 12, all depicted in Fig. 5A. The execution of a set of the instructions may in some cases result in output of data. Execution may also involve storing data or variables to the memory 534. The disclosed arrangements use input variables 554, which are stored in the memory 534 in corresponding memory locations 555, 556, 557. The disclosed arrangements also produce 25 output variables 561, which are stored in the memory 534 in corresponding memory locations 562, 563, 564. Intermediate variables 558 may be stored in memory locations 559, 560, 566 and 567. Referring to the processor 505 of Fig. 5B, the registers 544, 545, 546, the arithmetic logic unit (ALU) 540, and the control unit 539 work together to perform sequences of micro 30 operations needed to perform "fetch, decode, and execute" cycles for every instruction in the instruction set making up the program 533. Each fetch, decode, and execute cycle comprises: P032236_Speci_As Filed 6241977v] - 11 (a) a fetch operation, which fetches or reads an instruction 531 from a memory location 528, 529, 530; (b) a decode operation in which the control unit 539 determines which instruction has been fetched; and 5 (c) an execute operation in which the control unit 539 and/or the ALU 540 execute the instruction. Thereafter, a further fetch, decode, and execute cycle for the next instruction may be executed. Similarly, a store cycle may be performed by which the control unit 539 stores or writes a value to a memory location 532. 0 Each step or sub-process in the described processes is associated with one or more segments of the program 533 and is performed by the register section 544, 545, 547, the ALU 540, and the control unit 539 in the processor 505 working together to perform the fetch, decode, and execute cycles for every instruction in the instruction set for the noted segments of the program 533. 5 The described methods may alternatively be implemented in dedicated hardware such as one or more integrated circuits performing described functions or sub functions. Such dedicated hardware may include graphic processors, digital signal processors, or one or more microprocessors and associated memories. Fig. 3 shows a pixel-sequential renderer 300 which may be implemented, for example, on 0 the computer system 500. Modules 301 to 304 of the renderer 300, to be described, may be implemented as one or more software code modules of the software application program 533 resident on the hard disk drive 510 and being controlled in its execution by the processor 505. Alternatively, the modules 301 to 304 may be implemented in dedicated hardware such as one or more integrated circuits performing described functions or sub functions. 25 The renderer 300 comprises a display-list builder module 302 that receives drawing commands from one or more PDL interpreter modules 301. A markup language 310 may also be used by the processor 505 to process source data, in the form of PDL content 311, from one or more PDL interpreter modules 301. The markup language 310 determines Z-order of the PDL content source data 311, how the PDL content source data 311 is scaled and/or 30 transformed onto target media, as well as defining how the PDL content 311 is to composite with any underlying content P032236_SpeciAs Filed 6241977vl - 12 A display list 303 may be configured within the memory 506 and/or hard disk drive 310. The display list 303 consists of edges defining geometry of graphical objects. The edges may be sorted substantially in Y-order so that the edges can be traversed by a display renderer module 304 to produce scan-lines of pixel data for a target device, such as the printer 515. 5 Within a PPML script, one or more PDL content sources (e.g., 311), which may each be in different PDL formats, are encapsulated within a special display command known as a "group". Within any one of the PDL content sources in such a group, PDL defined compositing rules are active. In addition, the group may be associated with specific behaviours further defined by the PPML markup language, such as isolated/non-isolated or 0 knockout/non-knockout. When an isolated group is started, all succeeding graphical objects are rendered as if the succeeding graphical objects were on a white backdrop, without compositing or interacting in any way with any underlying content. Other types of groups with different backdrops are possible, such as a non-isolated group having a backdrop which is a copy of underlying content. 5 The above described groups may be found inside PDL content (e.g., 311), depending on the PDL, in addition to the groups added by PPML. Groups found inside PDL content do not affect operation of outside groups as groups may be nested indefinitely. When PDL content containing transparency is placed in an isolated group display command, objects will composite with each other according to behaviour defined by the PDL, 0 but not with the underlying content, as if the objects were rendered entirely separately. When the PDL content is ended, a group finish command is issued. The group finish command causes the result of compositing the group to be composited with the underlying content. In this instance, a compositing operation used to composite the group result with the underlying content may differ from compositing operations used to composite the PDL content within the 25 group. For example, in one arrangement of the renderer 300, any of the PDF blend modes may be used to composite the group result with underlying content, affording flexibility in composition and the graphical effects available. In addition, a transparency flattening operation may be applied to the group result as described below, according to one arrangement. 30 When graphical objects are placed in a group, from either within or between the PDL content sources 311 in PPML script, the graphical objects may be handled in a similar manner P032236_Speci_As Filed 6241977v] - 13 by the display list builder module 302 and the renderer module 304 may not be aware of the original PDL content source (e.g., 311) of the graphical objects. As an example, the pixel-sequential renderer 300 may be invoked to render a section of a horizontal scan-line 103 containing a background with an isolated group 100. The group 100 5 comprises an opaque object 101 and a semi-transparent object 102. Points where the scan-line 103 crosses the edges of the objects 101-102 define sections (or pixel runs) of the scan-line 103. In one arrangement of the renderer 300, each pixel run of the scan-line 103 may have an associated compositing list of levels 120 in Z-order to be composited, with levels in the 0 compositing list 120 corresponding to the Z-order of the objects. Five successive pixel runs (each with a corresponding compositing list) 111-115 within a group 100 are shown in Fig. 1. For each pixel in a run (e.g., I 11), operations in the compositing list 120 are carried out from the bottom up by the processor 505 using a compositing stack configured within memory 506. The following operations may be carried out by the processor 505 using the compositing 5 stack: (i) compositing operation between an object and the top-of-stack; (ii) pushing an object on the stack; and (iii) popping the top-of-stack and performing a compositing operation with the next-on stack. .0 In each case, the result of one of the above described operations is left as the top of the compositing stack. Having the compositing stack allows groups (e.g., 100) to be efficiently implemented within a particular rendering operation as the rest of a page being rendered. For the pixel runs Il l to 115 in Fig. 1, the evaluation of a compositing list 410 (see Fig. 4A) by the processor 505 for pixel run 113, for example, is shown in Figs. 4A and 4B. Fig. 4B shows 25 five states 401 to 405 of the compositing stack. As seen at 402 in Fig. 4B, the processor 505 pushes a transparent layer onto the compositing stack to create a group backdrop. The processor 505 then composites each object in the group 100 contributing to the pixel run 113 with the group backdrop as seen at references 403 and 404. Finally, as seen at 405 of Fig. 4B, the processor 505 pops the group 30 result from the compositing stack and composites the group result with the original background according to a compositing operation associated with the group. The other pixel runs 1 11, 112, 114 and 115 shown in Fig. I are subsets of the pixel run 113, because some or PO32236_Speci_As Filed 6241977v] - 14 all objects are not active. Furthermore, the compositing list 410 may be optimised to remove objects that do not contribute to colour of the result group. For example, pixel runs Ill and 115 contain no objects within the group 100. The pixel runs 111 and 115 are unmarked by objects from the group and starting and finishing levels of the group may be omitted 5 altogether during rendering pixels of the pixel runs I11 and 115, leaving the background unchanged. Other optimisations of the compositing list 410 may also be performed, such as removal of levels below a top-most opaque level, which do not contribute to the result colour. In the processing of a typical mark-up language, source content, which may consist of many graphical objects (e.g., objects 201 and 202 in Fig. 2) is contained within an isolated 0 group 200, and placed over a background. In order to perform transparency flattening in a Paint-As-Opaque or Strict-Paint-As-Opaque operation, the display-list builder module 302 introduces an additional level 220 to the list corresponding to for one or more pixel runs (e.g., 212, 213 and 214) based on a display list object which conditionally performs a Porter & Duff OVER operation to place the group result over an opaque white background. In particular, 5 the display list builder module 302 overlays the additional display list object with a compositing level of opaque white over other objects in a group of objects defined by a groupstart command and groupfinish command. Then, the display list builder module 302 overlays the result from rendering the group to be composited with a Porter & Duff OVER operation, with an opaque white background. As such, for transparency flattening, the 0 renderer 300 may perform the step of rendering an additional display list object with an opaque white compositing level (e.g., 220) for a plurality of objects in a group (e.g., 200). The mode of action of level 220 may be controlled by the markup language by sending commands to the display-list builder module 302 via the PDL interpreter module 301. As an example, a PPML 2.2 flattening operation may be executed using an additive colour space, 25 such as RGB, in one arrangement of the renderer 300. In such an example, if a value of the group alpha is greater than zero, a Porter & Duff OVER operation may be performed by the renderer module 304 between the group colour, the group alpha value and an opaque white background. The Paint-As-Opaque operation as specified by the PPML 2.2 specification is performed by 30 multiplying each colour channel by the group alpha value, and adding back a fraction of white background as detailed in the following pseudo-code (1), where white is represented by one (1) and black is represented by zero (0): P032236_SpeciAs Filed 6241977v] - 15 IF (group alpha > 0) { result R = (group R * group alpha) + (1 - group alpha) result G = (group G * group alpha) + (1 - group alpha) 5 result 3 = (group B * group alpha) + (1 - group alpha) result alpha = I } ELSE { 0 result alpha = 0 )1 pseudo-code (1) As another example, a PPML 2.2 flattening operation may be executed using a subtractive colour space, such as CMYK. In such an example, if the group alpha is greater than zero, a 5 Porter & Duff OVER operation may be performed, by the renderer module 304, between the group colour, the group alpha value, and an opaque white background. The Paint-As-Opaque operation as specified by the PPML 2.2 specification is performed by multiplying each colour channel by the group alpha as detailed in the following pseudo-code (2), where white is represented by zero (0) and nothing needs to be added back: .0 IF (group alpha > 0) { result C = (group C * group alpha) result M = (group M * group alpha) result Y = (group Y * group alpha) 25 result K = (group K * group alpha) result alpha = I } ELSE 30 result alpha 0 } pseudo-code (2) P032236_SpeciAs Filed 6241977v] - 16 A PPML 3.0 flattening operation is substantially similar to a PPML 2.2 flattening operation. However, for a PPML 3.0 flattening operation the group alpha value is not tested against zero and the OVER operation is always performed. The PPML 3.0 standard defines a "Strict-Paint-As Opaque" operation, where the flattening operation allows the processor 505, 5 for example, to render a pixel with an opaque white background in an event that the determined opacity value of the pixel is greater than or equal to zero. Accordingly, there is no test for the group alpha value to be larger than zero (0). In one arrangement, the renderer 300 may be configured to perform a flattening operation, using an RGB colour space, as a Strict-Paint-As-Opaque operation in accordance with the 0 following pseudo-code (3): result R = (group R * group alpha) + (1 - group alpha) result G = (group G * group alpha) + (1 - group alpha) result B = (group B * group alpha) + (1 - group alpha) 5 result alpha = 1 pseudo-code (3) Comparing the pseudo-code (3) for the flattening operation as specified by the Strict Paint-As-Opaque operation in PPML 3.0 as described above, with the flattening operation as .0 specified by pseudo-code (1) for the Paint-As-Opaque operation in PPML 2.2, the flattening operation in PPML 3.0 does not have the determining step of group alpha being larger than zero. As such, in an event that the opacity value of the pixel is greater than or equal to zero, pixels are rendered with an opaque white background. In accordance with another arrangement, the renderer 300 may be configured to perform a 25 flattening operation, using an CMYK colour space, as a Strict-Paint-As-Opaque operation in accordance with the following pseudo-code (4): result C = (group C * group alpha) result M = (group M * group alpha) result Y = (group Y * group alpha) 30 result K = (group K * group alpha) result alpha = 1 pseudo-code (4) P032236_Speci_As Filed 6241977vl - 17 Comparing the pseudo-code (4) for the flattening operation as specified by the Strict Paint-As-Opaque operation in PPML 3.0 as described above, with the flattening operation as specified by pseudo-code (2) for the Paint-As-Opaque operation in PPML 2.2, the flattening 5 operation in PPML 3.0 does not have the determining step of group alpha being larger than zero. As such, in an event that the opacity of the pixel is greater than or equal to zero, pixels are rendered with an opaque white background. For the operations described with reference to pseudo-code (3) and pseudo-code (4), all marked pixels have a result alpha of one (1), so an entire pixel run is known to be opaque. 0 Further simplifications of the compositing list are possible. Similar to Fig. 1, Fig. 2 shows five (5) successive pixel runs 211-215 (each with a corresponding compositing list) within the group 200. The evaluation of a compositing list 420 by the processor 505 for pixel run 214, for example, is shown in Figs. 4C and 4D. As described above, in the operations of pseudo-code (3) and pseudo-code (4), only 5 marked pixel runs are processed. In the operations described with reference to pseudo-code (3) and pseudo-code (4), unmarked pixel runs such as pixel run 211 and pixel run 215 have associated group levels which are optimised away and do not incur any computational penalty. Pixel runs that contain only group-starting and group-finishing levels (with no objects between the group-starting and group-finishing levels) are empty. Empty group pixel runs do 0 not affect the background colour, and so may be removed. In PPML terms, empty group pixel runs are unmarked. If the pixels are unmarked by objects within a group, the starting and the finishing levels of the group may be omitted during the rendering of the pixels in the group. In the processing of scan-line 203 of Fig. 2, pixel runs 212-214 are flattened. In the case of pixel run 212 and 213, the group result will be opaque because the group result has a contribution 25 from the opaque object 201. Hence, flattening operations such as the flattening operations described above with reference to pseudo-code (1), pseudo-code (2), pseudo-code (3) and pseudo-code (4), will not change the group result. However, the alpha value of the pixel run 214 is changed to one (1) as if the pixel run 214 is rendered directly over an opaque white background, as shown at reference 414 of Fig. 4D. As seen at reference 415 of Fig. 4D, the 30 result of a flattening operation is always opaque, as such a flattening operation replaces the background completely. P032236_SpeciAs Filed 6241977vl - 18 A method 600 of rendering an object on a page will now be described with reference to Fig. 6. The page is defined by a personalised print markup language (PPML). The object is rendered using the display list renderer module 304 of the pixel-sequential renderer 300 described above. As described, the pixel-sequential renderer 300 may be implemented as one 5 or more software code modules of the software application programs 533 resident on the hard disk drive 510 and being controlled in their execution by the processor 505. The method 600 begins at receiving step 601, where the renderer module 304 performs the step of receiving the object to be rendered. The object received at step 601 includes a flag or the like indicating if the object is to be rendered using the PPML 2.2 standard "Paint-As 0 Opaque" rendering operation described above or the PPML 3.0 standard "Strict-Paint-As Opaque" rendering operation described above. The value of the flag indicating which of the above rendering operations is to be used to render the object may be determined by the PDL interpreter module 301. At determining step 602, the renderer module 304 performs the step of determining an 5 opacity value of a pixel of the object on the page. Then, at rendering step 603, the renderer module 304 performs the step of rendering the object using the rendering operation indicated by the object. For the PPML 2.2 standard "Paint-As-Opaque" rendering operation, as described above, the renderer module 304 of the pixel-sequential renderer 300 renders the pixel with an opaque white background in an event that the determined opacity is greater than 0 zero. As also described above, for the PPML 3.0 standard "Strict-Paint-As -Opaque" rendering operation, the renderer module 304 of the pixel-sequential renderer module 300 renders the pixel with an opaque white background in an event that the determined opacity value is greater than or equal to zero. At decision step 604, if the renderer module 304 determines that there are further pixels of 25 the object to be rendered, then the method 600 returns to step 602. Otherwise, the method 600 concludes. As described above, in some arrangements, the object rendered in accordance with the method 600 may be contained within a special display command known as a group. In this instance, the starting and finishing levels of the group may be omitted during rendering the 30 pixels of the object. For example, as described above with reference to Fig. 1, the pixel runs I ll and 115 are unmarked by objects from the group and starting and finishing levels of the PO32236_Speci_As Filed 6241977vl - 19 group may be omitted altogether during rendering pixels of the pixel runs Il l and 115, leaving the background unchanged. In other arrangements, pixel data from incoming objects may be processed using substantially the same group compositing described above, using a modified "painter's 5 algorithm" to composite data onto a frame store configured, for example, within memory 506. Industrial Applicability The arrangements described are applicable to the computer and data processing industries and particularly for the image processing. 0 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 5 the word "comprising", such as "comprise" and "comprises" have correspondingly varied meanings. P032236_SpeciAs Filed 6241977v1

Claims (8)

1. A method of rendering an object on a page defined by a personalised print markup language (PPML), using a pixel-sequential renderer, said method comprising: 5 receiving the object to be rendered, said object indicating if the object is to be rendered using a PPML 2.2 standard "Paint-As-Opaque" rendering operation or a PPML 3.0 standard "Strict-Paint-As-Opaque" rendering operation; determining an opacity value of a pixel of the object on the page; and rendering the object using the rendering operation indicated by said object, wherein for 0 said PPML 2.2 standard "Paint-As-Opaque" rendering operation, said pixel-sequential renderer renders said pixel with an opaque white background in an event that the determined opacity is greater than zero, and wherein for said PPML 3.0 standard "Strict-Paint-As Opaque" rendering operation, said pixel-sequential renderer renders said pixel with an opaque white background in an event that the determined opacity value is greater than or equal to 5 zero.

2. The method of claim 1, further comprising rendering an additional display list object with an opaque white compositing level for a plurality of objects in a group display command. 0

3. The method of claim 1, wherein said object is contained within a group display command.

4. The method of claim 4, wherein starting and finishing levels of said group display command are omitted during rendering said pixel. 25

5. An apparatus for rendering an object on a page defined by a personalised print markup language (PPML), using a pixel-sequential renderer, said apparatus comprising: means for receiving the object to be rendered, said object indicating if the object is to be rendered using a PPML 2.2 standard "Paint-As-Opaque" rendering operation or a PPML 30 3.0 standard "Strict-Paint-As-Opaque" rendering operation; means for determining an opacity value of a pixel of the object on the page; and P032236_SpeciAs Filed 6241977vl -21 means for rendering the object using the rendering operation indicated by said object, wherein for said PPML 2.2 standard "Paint-As-Opaque" rendering operation, said pixel sequential renderer renders said pixel with an opaque white background in an event that the determined opacity is greater than zero, and wherein for said PPML 3.0 standard "Strict-Paint 5 As-Opaque" rendering operation, said pixel-sequential renderer renders said pixel with an opaque white background in an event that the determined opacity value is greater than or equal to zero.

6. A system for rendering an object on a page defined by a personalised print markup 0 language (PPML), using a pixel-sequential renderer, said system comprising: a memory for storing data and a computer program; a processor coupled to said memory for executing said computer program, said computer program comprising instructions for: receiving the object to be rendered, said object indicating if the object is to be 5 rendered using a PPML 2.2 standard "Paint-As-Opaque" rendering operation or a PPML 3.0 standard "Strict-Paint-As-Opaque" rendering operation; determining an opacity value of a pixel of the object on the page; and rendering the object using the rendering operation indicated by said object, wherein for said PPML 2.2 standard "Paint-As-Opaque" rendering operation, said .0 pixel-sequential renderer renders said pixel with an opaque white background in an event that the determined opacity is greater than zero, and wherein for said PPML 3.0 standard "Strict-Paint-As -Opaque" rendering operation, said pixel-sequential renderer renders said pixel with an opaque white background in an event that the determined opacity value is greater than or equal to zero. 25

7. A computer readable medium having a computer program recorded there for rendering an object on a page defined by a personalised print markup language (PPML), using a pixel sequential renderer, said program comprising: code for receiving the object to be rendered, said object indicating if the object is to be 30 rendered using a PPML 2.2 standard "Paint-As-Opaque" rendering operation or a PPML 3.0 standard "Strict-Paint-As-Opaque" rendering operation; code for determining an opacity value of a pixel of the object on the page; and P032236_SpeciAs Filed 6241977vl - 22 code for rendering the object using the rendering operation indicated by said object, wherein for said PPML 2.2 standard "Paint-As-Opaque" rendering operation, said pixel sequential renderer renders said pixel with an opaque white background in an event that the determined opacity is greater than zero, and wherein for said PPML 3.0 standard "Strict-Paint 5 As-Opaque" rendering operation, said pixel-sequential renderer renders said pixel with an opaque white background in an event that the determined opacity value is greater than or equal to zero.

8. A method of rendering an object on a page defined by a personalised print markup 0 language (PPML), using a pixel-sequential renderer, said method being substantially as herein before described with reference to any one of the embodiments as that embodiment is shown in the accompanying drawings. DATED this 30 th Day of April 2012 5 CANON KABUSHIKI KAISHA Patent Attorneys for the Applicant SPRUSON&FERGUSON P032236_Speci_As Filed 6241977v]