S&F Ref: P026916 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): Zdzislaw Sliwinski Daehan Choi Matthew Richard Frazer Nikos James Andronikos Peter Vincent Wyatt Address for Service: Spruson & Ferguson St Martins Tower Level 35 31 Market Street Sydney NSW 2000 (CCN 3710000177) Invention Title: Personalised print markup language The following statement is a full description of this invention, including the best method of performing it known to me/us: 5845c(6164692_1) - I PERSONALISED PRINT MARKUP LANGUAGE TECHNICAL FIELD OF INVENTION The current invention relates to the field of document processing, and in particular to the use of personalised print markup language (PPML) in document processing. 5 DESCRIPTION OF BACKGROUND ART PERSISTENT REUSABLE PDL DATA In the field of Variable Data Printing (VDP), it is common practice to process a large set of documents in preparation for printing or other further processing, in what is known as a "job". Documents are made up of pages that contain component document 10 objects, which are individual elements of a document such as graphics, text, images or resources. In a single Variable Data Printing job, it is usual that many documents within the job will share one or more component document objects as common to many pages. While performing the processing of a Variable Data Printing job, it is desirable to decrease the amount of time taken to process each document in order to increase the 15 efficiency of the processing. One commonly practiced method of decreasing document processing time is to eliminate unnecessary intermediate processing of document content wherever possible, while still preserving the integrity of the document data - that is, avoiding any loss of document information or content fidelity. In prior Variable Data Printing systems, this is achieved through the persistent 20 storage of a rasterised or display-list intermediate version of each component document object. However, this approach is still limited by the following shortcoming. When a component document object is used in a graphical context that is different to the one in which the intermediate version was originally generated, the integrity of the document content is compromised by using the stored intermediate version. In addition to this, 25 because the component document object was defined in a previous Variable Data Printing job, the unprocessed original version of the component document object is not available, so the option to reprocess the component document object to generate a new intermediate version is not available. In existing Variable Data Printing systems where the intermediate version of each 30 reusable component document object is stored, problems arise when multiple Variable Data Printing systems share the same persistent storage mechanism for the intermediate 6128666_1 P026916_speci -2 versions. Each Variable Data Printing system can make changes to the definitions of the objects in persistent storage as they are encountered in the respective Variable Data Printing jobs of each system. When two Variable Data Printing systems are simultaneously processing jobs that refer to the same component document object, these changes may 5 conflict and result in incorrect data being used by one or both systems. DEFERRED EXECUTION OF PDF COLOUR TRANSFORMATION FUNCTIONS In a conventional VDP system, the reusable graphics are rendered and stored in a cache as raster data, or more preferably as an intermediate form between PDL script and 10 raster data. Raster data has many disadvantages. For example, it is tied to specific colour settings, if the colour settings change then the raster data must be re-generated. Intermediate data however need not have this disadvantage while still allowing for the graphics to be re-used without the time consuming step of interpreting the source PDL. Sometimes, difficulties can arise when attempting to decouple the intermediate 15 format from the source PDL. This is a problem, for example, when the PDL script contains colour transformation functions. One solution is to store the PDL function definitions in the intermediate format as-is. The drawback to this solution is that the PDL interpreter instance and PDL data must remain in memory for as long as the colour transformation function may be called. This is because the PDL interpreter is the only module that understands the 20 format of the stored colour transformation function. Another solution to the problem that is known in the art is to sample the function. The drawback being an extreme memory cost. This is especially apparent for multi-dimensional functions and is difficult to overcome because the range of input parameters isn't known in advance. 25 SUMMARY OF THE INVENTION According to one aspect of the present disclosure, there is provided a method of processing a document, said document containing a reference to a graphical object identified for multiple use across a plurality of documents, said method comprising the steps of: 30 generating an encapsulated document describing the graphical object, said encapsulated documents comprising a complete definition of the graphical object; identifying a graphical context of the reference; 6128666_1 P026916_speci -3 determining at least one processed copy of the graphical object identified by the said reference, said processed copy associated with a graphical context in which the processed copy is generated; comparing the graphical context of the reference with the graphical context of the 5 processed copy; and processing the document by adding a new processed copy of the graphical object based on the encapsulated document without external input when the graphical context of the reference is different to the graphical context of the processed copy, said new processed copy of the graphical object being associated with the graphical context of the reference. 10 Desirably the method further comprises rendering the new processed copy of the graphical object to a rasterised image for use in one of the plurality of documents. Preferably the graphical context is a colour transform defining parameters for processing the graphical objects, said parameters depending on at least a printer capability and a medium that the graphical object is to be printed on. 15 According to another aspect there is provided a computer implemented method for deferred evaluation of parameterised colour transformation functions associated with a graphical object in a Page Description Language script, said method comprising the steps of: interpreting, using an interpreting module, the Page Description Language script to 20 generate a drawing call comprising the parameterised colour transformation function; converting the colour transformation function to a lossless parameterised independent representation for deferred execution in the drawing call using a set of additional context information in the Page Description Language script; said independent representation to be executed later independent of the interpreting 25 module or the Page Description Language script; removing the Page Description Language script from the interpreting module, removing the interpreting module from memory; and evaluating the lossless parameterised independent representation in the drawing call to obtain a result of the parameterised colour transformation function. 30 Advantageously the graphical object is one of a plurality of graphical objects used as a watermark. Other aspects are also disclosed. 6128666_1 P026916_speci -4 BRIEF DESCRIPTION OF THE DRAWINGS At least one embodiment of the present invention will now be described with reference to the following drawings, in which: 5 Fig. 1 is a schematic block diagram illustrating a Variable Data Printing System which processes Variable Data Printing jobs; Fig. 2 is a schematic flow diagram illustrating a method of efficient document processing wherein the documents have shared reusable content according to one embodiment of the invention; 10 Fig. 3 is a schematic flow diagram illustrating a method of searching for a compatible processed version of a component document object as used in the method of Fig. 2 according to one embodiment of the invention; Fig. 4 is a schematic diagram of a Personalised Print Markup Language (PPML) document referencing external reusable data according to one embodiment of the invention. 15 Fig. 5 is a schematic diagram of a Personalised Print Markup Language document encapsulating a reusable data object according to one embodiment of the invention; Fig. 6 is a schematic block diagram illustrating the components of a print system in the context of the invention; Fig. 7 is a schematic flow diagram illustrating a method of determining the output 20 target for drawing instructions describing graphics; Fig. 8 is a schematic flow diagram illustrating a method of converting and storing colour transformation functions that are required by a drawing call; Fig. 9 is an example of colour transformation functions described in the PDF Page Description Language syntax; and 25 Fig. 10 is an example of two other types of function: type two, exponential interpolation, and type three, stitching function. DETAILED DESCRIPTION INCLUDING BEST MODE OVERVIEW 30 The present invention describes a method for document processing of Variable Data Printing jobs in which global component document objects are efficiently stored and retrieved. 6128666_1 P026916_speci -5 Variable Data Printing (VDP) is a process used to create personalised documents. In VDP, some elements on the page contain variable data; they will be customised for the recipient. VDP jobs may also contain fixed data; this will look the same for each recipient. Typically, the variable data is single use and graphics that contain fixed data are 5 reused across multiple pages. VDP Page Description Languages often contain constructs to mark graphics as reusable; this is a hint to the RIP that the particular graphic should be processed such that it may be re-painted multiple times throughout the document efficiently. VDP jobs are processed by a RIP in much the same way traditional print jobs are 10 processed. The PDL script is fed into a print queue in the print system. A Raster Image Processor (RIP) retrieves the job from the queue. The RIP uses a PDL interpreter specialising in the format of the PDL to parses the job and build a model of the PDL script in memory. The PDL interpreter uses the model of the PDL script to generate drawing instructions which are sent to an output module were a display list is constructed. The 15 display list is a low level representation of the PDL script and is the last stage in processing before pixels are generated. The display list typically is dependent on particular device settings, finishing options and is represented in the output colour space. Graphic objects within the display list are not able to be translated from their assigned positions. The output module generates pixel data from the display list which is typically printed onto an output 20 medium. Some VDP PDLs are merely layout languages, they contain instructions to place graphics within pages as well as instructions to transform and clip those graphics. The actual graphics are described using other PDLs. The PDL scripts describing the graphics are referred to as source data. Typically graphics for reusable data will be cached within 25 the VDP PDL interpreter so that they may be reused as required. PERSISTENT REUSABLE PDL DATA During the processing of a Variable Data Printing job, a component document object within a document may cause an intermediate version of the component document 30 object to be generated that represents one part of the fully processed document. When a component document object is repeated on a single page, or across many pages within a document, or across many documents within a job, the processing that occurs to generate 61286661 P026916_speci -6 the intermediate version may be repeated for each occurrence of the component document object, thereby wasting time and reducing processing efficiency. Therefore, a common practice is for the intermediate version of a component document object, generated during the processing a specific Variable Data Printing job, to 5 be temporarily stored in the Variable Data Printing processing system, in order that each time the same component document object is encountered in a document or page within the job, the intermediate version may be retrieved from temporary storage to be included in the processed form of the document. It is typical that the processing cost of retrieving the intermediate version from storage is less than the cost of processing the component 10 document object to generate the intermediate version. When a Variable Data Printing job is being processed for the purpose of printing documents onto a physical medium, a usual intermediate format for component document objects is a rasterised image, or bitmap, of the component document object. The rasterised image represents the component document object in a form that is sufficiently similar to 15 the instructions required by the printing device so as to simplify any further downstream processing. The intermediate version of the component document object is generated for a specific document within a specific graphical context. A graphical context is a set of conditions or configuration settings that parameterise the processing by which the 20 intermediate version of the component document object is generated. The graphical context may include, but is not limited to, the following items: a) capabilities of the printer or printing device; b) calibration data of the printing device; c) properties of the medium being printed on; 25 d) properties of the specific colorants being used in the printing process; e) any transformation that is applied to the component document object such as rotation or scaling; or f) properties specific to a page or document When a component document object is shared among multiple documents in a 30 Variable Data Printing job, it is possible for each document to impose a different graphical context on the same component document object. In this case, the intermediate version that would be generated for a first document that includes a component document object may 61286661 P026916_speci -7 be different to the intermediate version that would be generated for a second document that includes said component document object. In this case, when the second document is processed, the intermediate version that is retrieved from temporary storage is an incorrect representation of the component document object, which will cause a loss of fidelity of the 5 second document in its processed form, according to the original definition of the document. To preserve the integrity of the second document, the Variable Data Printing system must reprocess the original component document object, thereby losing the advantage of storing the intermediate version of the component document object. Some Variable Data Printing jobs include component document objects that are 10 intended to be used in separate, future Variable Data Printing jobs. These component document objects are considered to be "global" component document objects, in that they are available to every Variable Data Printing job to be processed on the system in which they are installed. In this case, it is expected that the Variable Data Printing processing system will retain a representation of the global component document object in some kind 15 of persistent storage so that documents in future Variable Data Printing jobs can refer to the same global component document objects. In this case, it is still desirable for redundant processing of the global component document objects to be eliminated in order to increase processing efficiency. The efficiency is derived from the storage of component document objects in two 20 distinct forms: a) a first form that encapsulates the unprocessed definition of the component document object in such a way that processed intermediate versions of the component document object are generated without any external input and with minimal additional processing; and 25 b) a second form that contains a processed intermediate version of the component document object. A plurality of processed intermediate versions of the component document object may be stored, wherein each intermediate version is associated with a description of the graphical context in which the intermediate version was generated. A Variable Data Printing system that has processed a first document containing a 30 component document object and generated an intermediate version of that component document object, upon processing a second document containing said component document object, examines the description of the graphical context that is stored along with 61286661 P026916_speci -8 the intermediate version that was generated for the first document, and makes a determination as to whether the graphical context of the second document is sufficiently different from the graphical context of the first document as to warrant re-processing of the component document object in order to preserve the integrity of the document. In the case 5 where the stored graphical context is compatible with the graphical context of the second document, the stored processed intermediate version is retrieved and utilised in the processing of the second document without having to reprocess the component document object. A Variable Data Printing job that includes global component document objects 10 performs the same examination of the description of the graphical context to determine whether reprocessing is necessary. If the determination is made that the component document object requires reprocessing, then the encapsulated unprocessed definition of the component document object is used to generate the new intermediate version of the component document object without reference to the Variable Data Printing job in which 15 the component document object was originally defined. The new processed intermediate version is then stored to persistent storage in addition to any existing stored processed intermediate versions, and likewise is associated with a description of the graphical context in which the processed intermediate version was generated. A Variable Data Printing system that processes global component document objects 20 in a variety of distinct modes using different intermediate formats can store multiple variants of each global component document object for each different processing mode, while retaining a link between those different intermediate forms and the original definition of the global component document object. In the present invention, the Variable Data Printing system maintains a cache that 25 reflects the present status of each reusable component document object without reference to the persistent storage mechanism, said cache being maintained for the duration of the Variable Data Printing job. After the Variable Data Printing job has concluded processing, the Variable Data Printing system updates the persistent storage mechanism so that it reflects the correct state of each reusable component document object with respect to the 30 Variable Data Printing job that was just processed. These updates occur atomically - that is, every update operation is completed before any other Variable Data Printing system that shares the same persistent storage mechanism is able to make any other modification to the 6128666_1 P026916_speci -9 data in the persistent storage mechanism. In this way, the integrity of the document data is preserved in the case where multiple Variable Data Printing systems share a single persistent storage mechanism, and no conflict may arise from the simultaneous processing of multiple Variable Data Printing jobs. 5 Fig. 1 is a schematic block diagram illustrating a Variable Data Printing System which processes Variable Data Printing jobs. The Variable Data Printing system (100) comprises at least a Document Processor module (101), an Object Processor module (102) and a Persistent Storage mechanism (103). The Variable Data Printing system accepts as input a Variable Data Printing job 10 (104) which may describe zero or more documents for processing, each of which may reference component document objects stored in Object Storage (105). The modules 101, 102 and 103 are typically computer implemented by programming a general purpose computer system and executing the programs to perform VDP and for VDP evaluation. The Document Processor 101 will, in the course of processing the Variable Data 15 Printing job 104, communicate with the object processor 102 to coordinate the processing of individual component document objects. The Object Processor 102 will retrieve the necessary component document objects from the Object Storage 105. The Object Processor will also communicate with the Persistent Storage module 103 to enable the storage of object data according to the method of Fig. 2. 20 The result of the processing conducted by the Variable Data Printing system is zero or more documents (106) in a form dependent on the type of processing being performed by the Variable Data Printing system. Fig. 2 is a schematic flow diagram illustrating a method of efficient document processing wherein the documents have shared reusable content according to one 25 embodiment of the invention. In the first step of the method (201) a reusable object definition is encountered in the course of processing a Variable Data Printing job. The Variable Data Printing system identifies a reusable object definition by an explicit mechanism of the Variable Data Printing Page Description Language. In Personalised Print Markup Language (PPML), a common Variable Data Printing Page Description Language, 30 an XML element with a tag name "REUSABLEOBJECT" identifies the reusable object definition. 6128666_1 P026916_speci - 10 In step 202, the identifying properties of the reusable object definition are used to search the persistent store for a matching reusable object definition. The following steps are dependent on whether or not such a matching reusable object definition are found (203). In the case that a matching reusable object definition is not found at step 203, step 5 205 generates an encapsulated copy of the unprocessed reusable object definition and stores this encapsulated copy in the persistent store. This step is shown in greater detail in Fig. 3. After the encapsulated copy is generated, it is processed by the Variable Data Printing system into a processed version (208). The processed version is then stored in the persistent store (210) along with a description of the graphical context in which the 10 processing occurred at step 208. The processed version is also loaded into the Variable Data Printing System and used for further document processing at step 209, before this part of the method ends at 211. In the case that a matching reusable object definition is found at step 203, step 204 searches the persistent store for a processed version of the reusable object that is 15 compatible with the current graphical context. If a compatible processed version is found (206) then that version is loaded into the Variable Data Printing system (209) and used in further document processing. This part of the method then ends (211). If at 206 no compatible processed version is found, then step 207 loads the encapsulated copy of the unprocessed reusable object definition into the Variable Data 20 Printing System. This encapsulated copy is not a rasterised image, or bitmap, of the component document object because the rasterization of the object definition is possibly done under different graphical context which is not applicable in the current processing. After the encapsulated copy is loaded, the encapsulated copy is processed by the Variable Data Printing System at step 208, and the method proceeds as for the case when the 25 matching reusable object definition is not found at step 203. Fig. 3 is a schematic flow diagram illustrating a method of searching for a compatible processed version of a component document object as used in the method of Fig. 2 according to one embodiment of the invention. The method commences at step 301, and the method presumes that a reusable 30 object has been found in the persistent store, according to step 203 in Fig. 2. The first step 302 is to retrieve a list of processed version of the reusable object that have already been 6128666_1 P026916_speci - 11 stored in the persistent store. Step 303 determines if there are any stored processed versions that have not been considered by this method. In the case where there are stored processed versions remaining, step 304 retrieves the next processed version from the set of those remaining. In step 305, the graphical 5 context description stored along with the processed version is compared against the current graphical context. If, at step 306, the stored graphical context is found to be compatible with the current graphical context, then step 307 will select the processed version that was just retrieved at step 304 as the processed version to be used in 209 in Fig. 2. This method then ends at 309. 10 If at step 306 the stored graphical context is found to be incompatible with the current graphical context, then the control flow returns to step 303, so that remaining processed versions may be considered. In the case at step 303 where there are no processed versions remaining for consideration, step 308 informs the system that no compatible processed version is 15 available, and so the decision at step 206 in Fig. 2 will take the negative path to 207. This method then ends at 309. Fig. 4 is a schematic diagram of a Personalised Print Markup Language script referencing external reusable data according to one embodiment of the invention. A Variable Data Printing job may be described, in one embodiment of the 20 invention, by a Personalised Print Markup Language (PPML) script (401), which contains XML mark-up and other content relevant to the job. The PPML tag "<REUSABLE_OBJECT>" (402) identifies a reusable object definition within a Variable Data Printing job. The graphical content for the reusable object is stored in a separate file (407), which is referenced in the PPML script by an 25 "<EXTERNAL_DATA>" tag (403). This indicates to the Variable Data Printing system that the graphical content contained in the external file 407 is to be used wherever the reusable object definition is referenced within the PPML script. A second part of the reusable object definition is the "<OCCURRENCE>" tag (404) which contains the identifying properties of the reusable object definition, namely the 30 "Name" and the "Environment" attributes of the "<OCCURRENCE>" tag. The "Scope" attribute also signals to the Variable Data Printing system that this reusable object is suitable for persistent storage. 6128666_1 P026916_speci - 12 The PPML script 401 may also contain other content, such as non-reusable marks to be placed on a page, exemplified by the "<MARK>" tag 405, that reference other external graphical content files 408. The PPML script will also commonly contain a reference to the reusable object definition 406 that uses the identifying properties, namely the "Name" 5 attribute and the "Environment" attribute, to signify a reference to the reusable object defined by the "<REUSABLE_OBJECT>" tag 402. The PPML script 401 may contain many other features not described here, and the examples given are not limiting, but serve to demonstrate one typical usage of the present invention. 10 Fig. 5 is a schematic diagram of a Personalised Print Markup Language script encapsulating a reusable data object according to one embodiment of the invention. A reusable object definition (402) is used to generate an encapsulated instance of the reusable object (50 1). In one embodiment of the invention, the encapsulated instance is expressed as a Personalised Print Markup Language script (501). The 15 "<REUSABLEOBJECT>" element from the PPML script that originally defined the reusable object (402) is transformed to be included in the encapsulated instance as another "<REUSABLE_OBJECT>" element 502. The "<EXTERNALDATA>" element 403 is converted to an "<INTERNAL_DATA>" element 503. The contents of the external file 407 are included in the encapsulated instance using an appropriate encoding for the PPML 20 file, within the "<INTERNAL_DATA>" element 507. The "<OCCURRENCE>" element 404 is included in the encapsulated instance 504, with the identifying properties, namely the "Name" attribute and the "Environment" attribute, intact, but the "Scope" attribute removed. The "Scope" attribute is irrelevant, because this encapsulated instance is generated for the sole purpose of persistent storage. 25 In one embodiment of the invention, the encapsulated instance then includes a "<MARK>" element (505) which contains a reference to the reusable object definition 502. This "<MARK>" element places the reusable object onto a page within the encapsulated object instance so that when the encapsulated instance 501 is processed by the Variable Data Printing system, it will produce graphical output of the reusable object, rather than 30 only a definition of the reusable object. In other embodiments of the invention, the encapsulated instance may not include such a feature, and the encapsulated instance may only include a definition of the reusable object to be referred to and included in other 6128666_1 P026916_speci - 13 Variable Data Printing jobs. The reusable component document object may be a non graphical object, including objects such as a font resource, or a predefined graphics procedure, such as a PostScript ProcSet. In this case, the encapsulated instance would only contain the definition of the non-graphical component document object. 5 DEFERRED EXECUTION OF PDF COLOUR TRANSFORMATION FUNCTIONS Figure 6 shows an example architecture for a model print system 600 in the context of the invention. Print jobs, described using a Page Description Language (PDL) script, are fed to the Variable Data Printing (VDL) PDL interpreter 620 through the job queue 610, 10 the VDP PDL interpreter 620 parses print jobs, invoking external interpreting modules 640 to parse PDLs describing graphics; drawing instructions 660 are generated which are compatible with the output module 650. This can be used for deferred evaluation of parameterised colour transformation functions associated with a graphical object in a Page Description Language script. 15 The VDP PDL interpreter 620 also makes calls to the output module 650 to initialise the document, set parameters for pages, and other layout or finishing related operations. Depending on whether the page graphic is reusable or single use, the drawing instructions 660 are stored in a cache 631 by a caching module 630 or fed directly to the 20 output module 650 where a display list is built which is finally converted to pixels. In other words, if the page graphics is reusable, the drawing instruction is stored in the cache 631; on the other hand if the page graphics is single use, then the drawing instructions are fed directly to the output module 650 where a display list is built based on the drawing instructions. This display list is then used to render the pixels. 25 Drawing instructions 660 provide all the information required by the output module to render graphical objects. This data comprises information such as paths, bitmap data, font specification data, compositing operands and blend modes that is used to render the graphical objects. The drawing instructions also include function pointers to any colour 30 transformation functions. These function pointers point to the implementation of the colour transformation function in the interpreting module. When output module 650 is required to perform a colour transformation on an element within a graphic object, such as a fill or 6128666_1 P026916_speci -14 bitmap data, the output module 650 calls the call-back function with the colour value to be transformed, or the bitmap data and the colour transformation function returns the transformed input. The caching module 630 allows for drawing instructions 660 to be stored, in an 5 intermediate format, called a resource, which lies between the high level PDL script and the low level display list. Preferably the caching module and the output module implement the same interface. It is then a simple matter to re-paint a resource by feeding the drawing instructions 660 from the cache 631 to the output module 650 without needing to re interpret the PDL source data. Without the need to reinterpret the PDL source data, which 10 requires memory read and is more computationally complex, the current method of repainting the resource is faster, without loss of output quality as the drawing instruction is a lossless representation of the PDL source data. When caching a drawing call that contains a colour transformation function, the caching module 630 requests that the interpreting module convert the colour transformation 15 function to an independent format; that is, the colour transformation function is understood by any module external to the interpreting module 640. The conversion of colour transformation functions are the focus of this invention and are described in further detail below. The process of generating drawing instructions via the interpreting modules is 20 shown in more detail in Fig. 7. The VDP PDL interpreter 620 parses the PDL script and performs the operation described in Fig. 7 for each page within the document. The VDP PDL builds up a model of the document in memory as part of the parsing process. When a complete page and all its dependent constructs are parsed, the page can be processed to generate drawing instructions 25 for the graphics on the page. Starting with the first graphic on the page at 710 the interpreter determines whether the graphic is marked as reusable 720. If so, a resource will be created containing the drawing instructions that describe the reusable graphic. The drawing instructions are generated by an interpreting module 640. It is not 30 necessary for the interpreting module to know if the drawing instructions it is generating are creating a resource or are being sent directly to the output module 650 as the caching 6128666_1 P026916_speci - 15 module 630 and the output module implement the same interface for receiving drawing instructions. The VDP PDL interpreter 620 sets the target for the drawing instructions depending on whether the graphic is reusable 731 or single use 740. The target for the drawing 5 instructions is encapsulated within a drawing context. A drawing context contains the current state information for the output module interface such as colour space information, transformation matrices in effect, etc. While drawing instructions sent to the caching module 630 are stored, to be passed to the output module 650 later, drawing instructions sent to the output module 650 are 10 added to a display list which is ultimately rendered to pixels and output by the print system 600. Generally the output occurs while the VDP PDL interpreter 620 is processing a VDP PDL script or immediately once the VDP PDL interpreter 620 has completed processing the VDP PDL script. The VDP PDL interpreter 620 is not shut down until all output pages have been produced by the print system 600. 15 To interpret the graphic, which is described by a PDL script, an interpreting module 640 relevant to the PDL script is instantiated at step 750 and passed the graphic PDL script and the drawing context. The interpreter steps through its document model, built during parsing, and at step 760, tarting with the first graphic object described by the script, generates a drawing call 20 660, using the drawing context, describing the graphical object at step 761. In step 762, the interpreting module iterates over each graphic object described within the graphic PDL script. When the interpreting module has completed generating drawing instructions 660 it shuts down at step 770. At this time, the memory representation of the graphic PDL script 25 and all memory consumed by the interpreting module is released. Any reference within the drawing call to memory that was allocated by the interpreting module or to data in the PDL script will fail. The VDP PDL interpreter 620 continues processing at step 780 if there are more graphics on the page, otherwise the VDP PDL completes processing of the VDP PDL 30 script. Once the VDP PDL has completed processing of the VDP PDL script and the display list, built in the output module 650 is complete, the VDP PDL interpreter is shut 6128666_1 P026916_speci -16 down and all memory is released. The caching module is not shut down, but any resources created as a result of interpreting the VDP PDL script may now be deleted from the cache. Fig. 8 shows the operation of the caching module 630 as it is passed graphical objects from the interpreting module. The caching module 630 will store the drawing instructions 660 it 5 is passed so that they may be re-played later. The drawing call 660 is received at step 810 by the caching module 630. The drawing call 660 is stored within a resource in the cache. Resources are assigned a unique id so that they may be referenced in the future. As mentioned earlier, drawing instructions contain all information required by the 10 output module to render the graphical object. This data must be copied into the resource as no references to data in the interpreting module 640 are allowed. Drawing instructions may also contain strings and a font description. The glyphs required to represent those strings must be obtained from the font engine and stored within the resource. Preferably this glyph caching is performed in such a way that each glyph is 15 stored only once. If a drawing call has an associated colour transformation function; either a tint transform or transfer function, then from step 830, the processing proceeds to step 840 where the colour transformation function definition is requested from the PDL interpreter. Tint transform and transfer functions are defined through parameters in the PDL 20 file, as such they are referred to as parameterised colour transformation functions. Examples of parameterised colour transformation functions in the PDF language are shown in Fig. 9. The parameterised colour transformation functions are defined using the PDF function object syntax. PDF functions take n inputs and return m outputs. The output to the function provides the result of the parameterised colour transformation function. 25 The parameters 901 and 911 describe the type of function, the inputs and outputs, and the encoding for the additional context information in the stream 902 and 912. In most cases, the additional context information provides the data that defines how the input values are evaluated to determine the output values. Function 900 is a PDF type zero function, this is a sampled function where the 30 additional context information in the stream 902 defines an n dimensional table of samples. Each sample is made up of m components. The inputs to the function index into the table 6128666_1 P026916_speci - 17 of samples to obtain output values. Inputs falling between two samples are interpolated according to the PDF specification. Function 910 shows another type of PDF function, the type four, or PostScript calculator function. The additional context information in the stream 912 is a subset of the 5 PostScript language. This program stream 912 must be executed to evaluate the result. Interpretation of the PostScript program stream requires a PostScript interpreter that supports at least the PostScript Calculator operators. The PDF language also defines two other types of function; the type two, exponential interpolation, and the type three, stitching function. These are shown in Fig. 10 10. Exponential interpolation functions 1000 are defined purely through parameters 1001 and there is no need for additional context information. The parameters 1001 define the function result when the input equals zero and when the input equals one as well as the interpolation exponent. 1 5 Stitching functions 1010 are a composite type; mapping different portions of the input domain to other functions, including other stitching functions. The parameters 1011 include references to the other functions and describe how each function is mapped into the domain using the /Bounds entry. It is important to note that a stitching function may reference another stitching function and this creates a tree structure with the nodes being 20 Type 0, Type 2 or Type 4 functions. The functions 900, 910, 1000 and 1010 are in a format specific to the PDL, and the additional context information comes from the PDL script so a PDL interpreter is required to evaluate the result of the function. Additionally, functions such as the PDF type four function require a PDL interpreter to perform lexical analysis, parse, and interpret a 25 PostScript program. To allow for converting of colour transformation functions, the interpreting module 640 must provide facility for the caching module 630 to retrieve a lossless definition of the parameterised colour transformation function and the additional context information. The information returned by the interpreting module 640 is in an independent format. 30 To execute colour transformation functions the interpreting module 640 provides functions through an external interface. These functions typically take an input colour, in a 6128666_1 P026916_speci - 18 format defined by the output module 650, and output the transformed colour in the same format. Optimised versions may be passed an entire bitmap for colour conversion. The interface through which the caching module 630 retrieves the parameterised colour transformation function definition is implemented through the same external 5 interface. Going back to Fig. 8 the branch that occurs when a transformation function is present within a drawing call leads to step 840 where the caching module 630 requests the colour transformation function definition from the interpreting module 640. This request comes from the caching module 630 and is made via the interface implemented by the 10 interpreting module When conversion is complete at step 841 and the lossless parameterised independent representation is returned to the caching module 630, the lossless parameterised independent representation is stored within the resource to which it belongs and the drawing call is updated to refer to the cached independent representation instead of 15 the original representation in the PDL interpreter. The conversion process occurs within the interpreting module 640. The interpreting module converts its internal representation for the colour transformation function at step 841 and return the lossless parameterised independent representation to the caching module 630. 20 Conversion of the parameters defining the colour transformation function is straight forward; these are numeric types so no special operations are required. Conversion of the additional context information shall be specified with respect to the function types defined in the PDF specification and described previously. PDF type zero functions 900 use a table of samples to perform colour conversion. A 25 memory efficient PDF interpreter may store these samples in memory or on disk, depending on available memory in the print system. Sample table data will require no specific conversion, as it is simply numeric data. However, the PDF interpreter must read the data from disk and provide it to the caching module 630 using data types understood by the caching module 630. 30 PDF type one functions are described only through parameters so no special processing is required. 6128666_1 P026916_speci -19 PDF type four functions are dependent on a PostScript interpreter; this dependence must be removed to satisfy the requirements of the common format. In the preferred embodiment of the invention, the PostScript program is converted into another executable format. This is achieved by performing lexical analysis of the 5 PostScript program and tokenising to a common format which is defined as part of the independent representation. A parser and evaluator for the common token format are implemented in a common module, accessible to the caching module which implements the colour transformation call-back functions. PDF type three functions can be converted to a tree representation where each node 10 represents a portion of the input domain. The leaf nodes are references to other converted functions. After the returned independent representation is stored, processing continues at step 850 where, if there are more drawing instructions, the branch loops back to step 810, otherwise processing ends. At this point, the resource in the cache is complete. 15 In one application of the invention, resources are used for Personalised Print Mark up Language (PPML) reusable object occurrences. PPML is a VDP layout Page Description Language. PPML reusable objects are graphics which are marked as reusable; the source data for the graphic is described using a PDL such as PDF, PostScript or an image format such as JPEG. 20 In a second application of the invention, the resources are used for watermarking; the watermark is specified using a PDL script and the resource generated is painted onto all pages of the document or some pages, as configured by the user. 6128666_1 P026916 speci