WO2005122010A1

WO2005122010A1 - Method and system for in-rip processing and printing of variable documents

Info

Publication number: WO2005122010A1
Application number: PCT/GB2004/002857
Authority: WO
Inventors: Abraham Adizes
Original assignee: Icon Biometrics Plc
Priority date: 2004-06-10
Filing date: 2004-07-01
Publication date: 2005-12-22

Abstract

The present invention provides a method and system for in-RIP processing and printing of variable documents. The method of the invention comprises generating a page description language (PDL) file defining said fixed and variable elements and a data file defining instances of said variable elements, and processing the PDL file in conjunction with the data file in a raster image processor (RIP), to render the variable document into the image memory of a digital output device. The invention further comprises subjecting the variable elements to transformation according to algorithms comprised in the PDL file. In a further aspect, the method comprises in-RIP imposition of multiple instances of the variable document. In this aspect, the PDL file comprises a loop, or a series of nested loops processed to render one or more instances of the variable document. The system of the invention comprises a software application capable of generating the PDL files and the data files according to the present invention, a RIP capable of processing said PDL files in conjunction with said data files; and a digital output device connected to said RIP and capable of printing documents according to the invention.

Description

Method and System for In-RIP Processing and Printing of Variable Documents TECHNICAL FIELD The present invention relates to digital printing methods and systems and, more specifically, to a method and a system for processing and printing of variable documents.

BACKGROUND OF THE INVENTION In conventional printing, a page layout to be transferred to the print medium is generally prepared by composing a page consisting of one or more elements such as text, line-art and images; using a photographic process to transfer such page onto a sheet of graphic film; developing the film; cutting and pasting appropriate sheets of film to obtain a printing spread; using a photographic process to transfer the layout from film to a photosensitive plate; and developing the plate. This process is generally referred to as prepress. The plate is then used m a printing press to produce multiple copies of the page layout One plate is typically used to transfer one appropriately colored ink onto the printed copy. It is impossible, or at least impractical, to print all the shades of a particular color by using multitude of plates and multitude of differently shaded inks. A process of halftoning achieves various degrees of color intensity by exposing the page layout onto the graphic film through a screen comprised of a series of uniformly ordered dots, so that areas of higher intensity are rendered with larger dots and lighter areas are rendered with dots of smaller diameters. The fidelity of rendering depends on the fineness of the screen.

Similarly to varying shades of the same color, it would be impossible to achieve a full-color effect by utilizing multitude of plates and differently colored inks to render all the colors and shades present in, for example, a color photograph or an oil painting. Therefore, a complete range of colors and shades are emulated using a process of combining three basic colors - cyan, magenta and yellow. To achieve better contrast, and to provide for easier rendering of objects such as text, black color is added to arrive at a four-color, or CMYK process. In preparing the job for printing, therefore, the page layout must be transferred onto the graphic film using both screens and color filters, to arrive at four sheets of film referred to as separations. After assembling the printing spreads, separations are transferred onto four plates and used to print a full color job. Instead of, or in addition to cyan, magenta, yellow and black (also known as process colors), a varying number of other color separations may be employed. This approach is mainly used when a page does not comprise full color objects, or if CMYK process can not efficiently emulate the required colors. Examples of such colors include metallic colors, e.g., gold or silver, white on a colored or transparent substrate, fluorescent colors, etc. Colors other than CMYK are generally referred to as spot colors or special colors. With the advent of computers, applications have been created in order to automate an increasing number of sensitive, tedious and labor-intensive prepress operations. After an initial period in which market was dominated by complex and highly proprietary hardware/software systems, these applications have evolved in two groups - page layout or publishing applications, and raster image processors or RIP applications. Page layout applications are used for creating the layouts and are generally device-independent, which means that a layout can be composed regardless of the device that will be used for outputting it onto the film. RIP applications are, on the other hand, designed or customized to work with a specific film output device, or imagesetter. A number of software packages, such as graphic design applications, word processors, etc., are available for the purpose of designing or creating the graphic elements, also referred to as digital assets. Page layout applications are, conversely, generally used to manipulate assets created by other applications, or digitized (e.g., by scanning), in order to create finished page layouts. A finished layout, composed within certain "space," is device-independent (within obvious limitations, such as tie page size) and incorporates objects such as text of appropriate typeface and size, line-art and images. The device-independent space is often referred to as the "user space." Manipulating complex graphic objects, such as high-resolution images or multi-layered groups of line-art elements, may put an unnecessary strain on the limited computing resources. Since the main purpose of a page layout application is not to create or edit the digital assets, but rather to manipulate them within the page layout, the strain on the resources may be lowered by replacing complex assets with their simplified, low-resolution previews. The finished layout, therefore, may incorporate only the previews of more complex page elements.

The other group of prepress applications, RIP applications, handle the layouts created in the device-independent user space, convert them to the "device space" of a specific output device, and feed the "image memory" of the device with a stream of data necessary for outputting the job. In essence, RIP works to flatten down a multi-layered layout and rasterize type and line-art, replacing traditional operations of screening and color separation. If the layout was composed using page element previews, RIP may also replace them with original high-resolution assets to be processed. Because of the amount of processing required, large file sizes and amounts of computer memory necessary for rendering, ripping usually takes place on dedicated, powerful machines utilizing cutting edge computer technology.

After initial proprietary systems gave way to a variety of software and hardware solutions and vendors, it had become necessary to standardize the output of page layout applications and to create a page description language (PDL) which may be interpreted by various RIP applications in order to feed different output devices. The PostScript language (Adobe Systems Incorporated, San Jose, California) has become recognized as one of the most robust and versatile PDLs. In addition, PostScript is not only device-independent but also platform- independent, which means that it can be created and interpreted by applications running on various operating systems. For those and other reasons, PostScript (now at its Level 3) serves as a de facto standard in the printing industry. In addition to describing page layouts to be output on film, the PDLs have been increasingly used for layouts to be printed on laser and inkjet printers, and even to drive screen displays. On the other hand, drivers developed for screen output in graphical user interface (GUI) environments have become robust enough to be used as PDLs for outputting relatively simple layouts on desktop printers. Thus, for example, Windows metafile, used in Windows GDI (graphical display interface), serves as a page description language in printing on (R) Microsoft Windows™ platform (Microsoft Corporation, Redmond, Washington). More recently, increased computing power of dedicated RIP stations has allowed for larger printing spreads to be output in a single job, with the result that rendering separations on film is no longer necessary. Separations can be rendered directly on photosensitive plates, using devices known as platesetters. This process is referred to as computer-to-plate (CTP).

Desktop printers were initially used for outputting text in a limited number of built-in typefaces. Increased computing power and faster storage devices have, however, enabled them to process complex page layouts with ever-increasing speed and reliability. The logical next step has been the development of large, high-speed printing devices referred to as digital presses. In a fully digital workflow, layouts are ripped into the image memory of a digital press, and then used for direct output on the print medium without the need to create either film or plates. The ability to print directly has tremendously increased the flexibility of the printing process. Without expensive and time-consuming preparation of film and/or plates (followed by so- called "make-ready" of the lithographic press), a print job can be output much faster. In addition, extremely short runs have now become economically feasible. As a result, although less than a decade old, digital printing technology already serves significant niche markets and has begun to enter the mainstream of printing industry.

Traditional printing generally involves printing multiple copies of the same page layout. Variable printing, conversely, denotes a workflow in which one or more elements of the layout are varied from copy to copy. Before the advent of digital presses, the only way to achieve these results on a mass scale was to pre-print the fixed elements of the page layout and then, in a separate step, to add variable information using a different output device. Not surprisingly, such a procedure involved significant additional costs and was limited to adding - single-color textual information (such as e.g., address or title), to a pre-printed form. One of the advantages of the direct output on a digital press is the ability to vary the page layout from copy to copy. Thus, for example, a complete book may be printed in a collated order as a single continuous job. The size of the book is limited only by the capacity of the image memory, and the printing speed (apart from mechanical considerations) depends only on the rate at which data can be transferred from the image memory to the print heads. However, after an initial enthusiasm provoked by seemingly endless possibilities of varying the contents of page layouts, the industry has encountered a series of problems stemming from a wide gap between the capacity, flexibility and speed of prepress operations and, on the other hand, output capabilities of a digital press. In traditional printing, outputting a copy of the page layout requires only a small fraction, of the time needed for prepress operations. Page layout applications took a long time to output PDL files of enormous sizes. In the same way, early RIPs typically required hours, and sometimes days, to render separations of a large high-resolution image or a complex set of line-art objects. As long as the output medium was film or a plate, this was not a serious problem. Once -the plates were created, the process of lithographic printing could proceed at regular speed. Similarly, in digital printing, once the page layouts are ripped into the image memory, printing may proceed at nominal speed of the digital press. Printing variable contents integrally with the fixed elements of the layout, however, means that each specific layout will be printed only once. The capacity, speed and economic feasibility of variable printing become directly dependent on the asset management capability, flexibility and speed of page layout processing. Printing a variable job using conventional PDL output boils down to the creation of a standard multi-page file, where each page differs from the previous one only in contents of certain fields. Although software applications have been created - for the most part "plug- ins," or "extensions" of standard page layout packages - to replace manual placement of the variable elements with automated, database-driven "binding" of pages, the PDL output still has to be processed by the RIP as if it were a conventional job, one page at a time. The redundant processing, in both PDL generation and ripping stages, becomes a prohibitive factor in the degree of variability that can be achieved. Regardless of the computing power deployed, time, memory and storage capacities required are enormous. The job size has to be severely limited and, if any assets other than simple text are involved, the time ratio of processing vs. printing is seldom lower than 6:1.

There are two main obstacles to using standard PDLs, such as PostScript, for more efficient processing or variable jobs. The first is intrinsic to the device-independent nature of such languages, which results in a severely limited degree to which they can reference and manipulate image memory (which, of necessity, is device-specific). The second obstacle is that applications that generate PDL output, created for the purposes of traditional printing, generally lack features that would provide for efficient external referencing and resourcing, database connectivity, API calls and other features important for variable processing.The solutions proposed and utilized in the variable printing industry have so far been concerned with the post-RIP, device-resident processing of fixed or repeat elements. Thus, for example, Xeikon digital presses (Xeikon International, Lier, Belgium), in conjunction- with a very fast image memory, provide for the print-time "collating" of one or more pre- ripped master layouts with individual pages of a separate PDL file comprising only variable elements. More recently, Xeikon collator was enabled to handle pre-ripped elements in an object-oriented way, which has greatly reduced redundant ripping and image memory requirements when printing jobs comprised of a large proportion of repeat elements. The "front end" generation of the PDL output has, however, remained essentially unchanged. Other notable solutions include the Creo Variable Print Specification (Creo Incorporated, Burnaby, British Columbia; formerly CreoScitex), and JLYT™ for Indigo digital presses (now a part of Hewlett-Packard, Palo Alto, California), both of which provide for cashing and more efficient handling of fixed and repeat elements, while relying on a more-or-less standard PDL generation. On the PDL generation "front end" side, improvements have been achieved in binding of variable pages" implemented in certain proprietary solutions, most notably in Barco Graphics' VIP -Line (appropriate division of Barco Graphics is now Dotrix nv, Gent, Belgium). However, in spite of improved binding and more efficient external referencing, the solution still outputs a conventional, page-by-page based PDL file.

In spite of numerous improvements, there is still a pressing need for more efficient variable printing solutions, particularly in projects requiring complex digital asset management and involving large quantities of graphically demanding, non-repeatable page elements. Such projects are, specifically, characteristic of the security document industry. The security document industry has recently been faced with a need of providing passports, visas, ID cards and other personalized documents with an increased sophistication of security features and at much higher production levels than before. Implementation of a fully variable digital workflow in this field has, however, been rather slow due to numerous problems arising from extreme complexity and volume of data to be processed.

To facilitate efficient processing and digital printing of variable documents, the authors have undertaken to develop a method for direct, in-RIP processing of variable, non-repeatable digital assets and data, as well as other in-RIP processing features which will become apparent to a person skilled in the art from the following description of the invention and preferred embodiments thereof.

SUMMARY OF THE INVENTION The present invention provides a method and system for in-RIP processing and printing of " variable documents, wherein the document layout comprises at least one fixed element and at least one variable element. The fixed and variable elements of the document layout may comprise text, line-art, and images. The method of the present invention comprises generating at least one page description language (PDL) file defining said fixed and variable elements and at least one data file defining at least one instance of said variable elements; and processing said at least one PDL file in conjunction with said at least one data file in a raster image processor (RIP), to render said at least one instance of the variable document into the image memory of a digital output device. According to the first aspect of the present invention, the variable elements of the document layout are defined as variables within the PDL code, said PDL variables being assigned appropriate values by parsing said at least one data file during in-RIP processing of the variable document. In addition to values assigned directly from the data file, the value may be obtained by concatenating values of at least two other PDL variables, or by concatenating values of one or more PDL variables with a fixed string defined in the PDL file. One PDL variable may define a single element, or multiple elements of the document layout. In one embodiment, values assigned to the PDL variables are rendered as text of a predefined typeface and size. In another embodiment, the PDL variables are rendered in a machine-readable form, e.g. as bar codes. In yet another embodiment, the value of a PDL variable is not directly rendered, but rather comprises a path and/or filename of an external digital asset which will be rendered during processing of the variable document. In another aspect of the present invention, the value of the PDL variable may be subjected to a transformation according to an algorithm comprised in the PDL file. Such transformations include, without limitation, case conversion, character suppression or replacement, date format conversion, truncating, padding, and generation of specific machine-readable elements. ^!

In a further aspect of the present invention, the method comprises processing multiple instances of the variable document. In this aspect, the PDL file comprises at least one loop processed to render multiple instances of the variable document. The at least one loop is preferably processed until all the instances of the variable document are rendered.

According to one embodiment, each instance of the variable document is rendered into the image memory of the digital output device as a separate page, According to another embodiment, each page rendered into the image memory comprises multiple instances of the variable document. In this embodiment, the PDL file comprises a series of nested loops, which are processed to render multiple instances of the variable document. The page comprising multiple instances of the variable document is rendered by processing the series of nested loops so as to position the instances of the variable document -in rows and columns. The number of rows and columns depends on the page size of the digital output device.

In still another embodiment, the PDL file, in addition to defining fixed and variable document elements and the imposition of multiple documents on the page, defines additional page elements. Similarly to the document elements, the page elements may be fixed and variable. According to this embodiment, a single data file may define the multiple instances of both variable document elements and variable page elements, or one data file may be generated for variable document elements and another data file for variable page elements. In yet another embodiment, the PDL file, in addition to pages comprising multiple instances of the variable document and optional page elements, defines at least one additional page. According to a still further aspect of the present invention, the PDL files may be processed to render the fixed document and/or page elements separately from the variable elements. In one embodiment, one PDL file defines both fixed and variable elements, while in another embodiment at least one PDL file defines the fixed elements and at least one PDL file defines the variable elements of the document and/or page layouts. In one embodiment, the fixed elements are rendered into the image memory as a complete page layout. In another embodiment, the fixed elements are rendered into the image memory as one or more dynamic page elements. According to this aspect, the digital output device is capable of merging fixed and variable pages or page elements rendered into the image memory, and the method of the present invention further comprises generating a control file with instructions for merging said fixed and variable pages or page elements. In the final aspect, the present invention comprises a system for in-RIP processing and printing of variable documents. The system of the present invention comprises a software application capable of generating the PDL files and the data files according to the present invention; a RIP provided with a direct access to said PDL files and data files, capable of processing said PDL files in conjunction with said data files; and a digital output device connected to said RIP and capable of printing documents according to the invention. In one embodiment, the software application is capable of generating at least one PDL file defining fixed and variable elements of the document layout and at least one data file defining instances of values of said variable elements. The PDL file is passed to the RIP capable of processing said PDL file in conjunction with said data file, and rendering the document elements into the image memory of the digital output device capable of printing the documents according to the invention. In another embodiment, the software application is capable of generating at least one PDL file defining fixed and variable elements of the document layout, at least one data file defining instances of values of said variable elements, and a control file. The at least one PDL file is passed to the RIP, which is capable of processing the fixed elements and • rendering them into the image memory of the digital output device. The RIP is further capable of processing the variable elements in conjunction with said data file and rendering them into the image memory of the digital' output device separately from the fixed elements.

In this embodiment, the fixed elements may be rendered into the image memory as a complete page layout, or as one or more dynamic page elements. The digital output device is capable of merging the fixed and the variable elements, according to instructions comprised in said control file, and printing the documents according to the invention. BRIEF DESCRIPTION OF THE DRAWINGS Figure 1 illustrates a typical document printed using the method and system of the present invention, featuring a number of elements defined as variables; Figure 2 illustrates the same document, with an added element in which an external digital asset is referenced by another variable; Figure 3 shows a section of the document of Fig. 2, wherein another element is added, this time composed by concatenating multiple variables; Figure 4 depicts the same document as in Fig. 2, wherein the same external digital asset, referenced by the same variable, is rendered twice using a different procedure; Figure 5 is a schematic representation of two pages of a variable job according to this invention, illustrating the dynamic, in-RIP imposition of individual documents and page- level elements; Figure 6 illustrates the same document as in Fig. 1, wherein a machine-readable element is added using in-RIP generation; and Figures 7 to 9 are diagrams illustrating various embodiments of the system of the present invention. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Page layouts are created using a number of different page layout applications and incorporating digital assets (such as line-work, images, etc.) created to conform to a wide variety of file formats and compressions. While contemporary page layout applications are generally able to handle most of original digital asset formats, they achieve it at a major cost in terms of runtime overheads - large amounts of data have to be pre-processed and converted in order to fit the assets into a required format. Significant part of such overhead may be passed on to the PDL output, only to be encountered again at the ripping stage. • In variable printing, different applications, "plug-ins" or "extensions" available to the graphic design community handle variable graphic elements in a highly non-standard manner. In their native formats (although not in the final PDL output which, as mentioned above, generally remains conventional), such applications may handle variable graphic elements as separate documents, as individual pages of a multi-page subdocument, as multiple layers of the same page layout, etc. While the diversity of layouts and assets may generally require the full processing apparatus provided by the above applications, it will not always be the case. In the workflow generally referred to as "personalization" the layouts are strictly defined, and the size, format and placement of fixed and variable page layout elements remain the same throughout the life of the project, which may involve tens of millions of documents printed over a number of years. Although variable assets are generally non-repeatable, and typically represent the bulk of data to be processed, they are highly structured. Such workflows are typical of the security document industry. Thus, for example, even though an ID card project may involve printing of millions of photographs, they will typically have consistent format, compression, size and resolution, and will be named in a systematic manner. Similarly, alphanumeric data will be stored in, or exported from, a structured database. A structured system enables the PDL output to be generated in such a manner that conversion and re-organization of digital assets and data is kept at a minimum, or even rendered completely unnecessary.

Before turning to a detailed description of the invention, a few remarks should be made. To ensure a better understanding of the concepts taught in this specification, a distinction should be made between the two uses of the word "variable." When used as an adjective in conjunction with "document element," "page element," "digital asset," etc., it denotes a graphic element (text, image or another graphic feature) that changes from one instance of the document to the other. Thus, for example, the specification uses terms "variable document element" or "variable asset." When used as a noun, the word "variable" denotes a computer program variable, as in "PDL variable," "assigning value to a variable," etc. The second remark is regarding the samples of the code provided in this specification: (1) for convenience, partial PostScript listings will be used throughout the application, although the invention is by no means limited to implementations in any particular PDL; (2) each sample listing represents only relevant portions of the PDL code, where the segments are separated by a "% " line; and (3) it should be noted that all code samples provided in this application are subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of this specification or ensuing patent documents, but otherwise reserves all rights whatsoever.

According to the first aspect of the invention, structured digital assets and data are defined as variables within the PDL code. As a result, there is no need for PDL output to consist of a page-by-page description of all instances of variable document. Instead, the PDL definition • of a single document, comprising both fixed and variable layout elements, is submitted to the RIP. During processing of the PDL code (ripping), variables are populated with values from a corresponding data file and rendered directly into the image memory. The PDL code is interpreted in a loop for as long as there are records in the data file, or until a certain predetermined number of pages have been reached. In one embodiment, illustrated in Fig. 1, the document layout comprises a number of alphanumeric elements, designated as f_01 to f_09. A partial code listing is provided as an example of initializing variables when using PostScript as a PDL.

It 01 30 string def IS Last name It 02 30 string def "o First name It 03 20 string def Addres line 1 If 04 20 string def Address line 2 I f 05 20 string def g, "6 Address line 3 It 06 15 string def Card number It 07 15 string def £. Date of issue It 08^' 15 string def ~6 Personal number /f_09 1 string def sex

In the fictional Utopian ID card depicted in Fig. 1, the variable elements are defined by string variables, although other data types may be employed. Fixed elements (such as title lines and captions) are defined in a traditional way. In a manner which will be explained in a greater detail later, the values of the PDL variables are obtained by parsing an appropriate data file. As the PDL code is always generated for a specific purpose, the string length may be limited to a pre-defined maximum number of characters, which reduces the amount of memory required and speeds-up the processing. The incorporated values are rendered directly into the image memory. In another embodiment, Fig. 2 illustrates the manner in which digital assets existing as external files may be referenced. Instead of being rendered as text, the variable defines a full path and filename of the file passed to an image decoder (or, in PostScript terminology, a filter) as a data source.

/f_10 255 string def % photo filename /Data f 10 (r) file def

The complete value of the f_10 variable may be, for example, 's : /utopia/assets/images/dj 123456. jpg.' This syntax will be used when ripping on Windows or Unix platform; if the ripping is done on Macintosh platform, the syntax would be ^ls : utopia : assets : images : dj l23456. jpg.' It will be obvious to a person skilled in the art that external assets may come in different ' formats, which does not pose a problem as long as the RIP is equipped with an appropriate filter. Thus, for example, RGB or CMYK color images may come in JPEG format, while single-color images may come in TIFF format, compressed using CCITT G4 compression. Also, it is obvious that the external assets may reside in any network folder accessible to the RIP host and may be read directly, without having to be copied to the host machine. In a further embodiment, a number of PDL variables may be combined to form a new variable, which is then rendered in the document. The micro text (f_l l) around the photograph in Fig. 3 is an example of one such variable, obtained by concatenating strings f_02, f_01 and f_07, with space characters (ASCII value 32) in between. Rendering text along a path shall, in itself, be apparent to those skilled in the art.

/f_ll f_02 length f_01 length add f_07 length add 3 add string def f_ll 0 f_02 putinterval f 11 f 02 lenth 1 add 32 put % (add space character) f 11 ^•f 02 length 2 add f_01 putinterval f 11 f 02 length f_01 length add 2 add 32 put f 11 f 02 length f_01 length add 3 add f_07 putinterval f 11 f 02 length f_01 length add f_07 length add 4 add 32 put

Similarly, variables may be concatenated with fixed strings. For example, if the image folder path is always the same and if the name of the image file always corresponds to the personal number (f_08), there is no need to burden the data file with duplicate fields. Value of f_10 may be obtained by concatenating the fixed path string (in our example 's : /utopia/assets/images/') with the f_08 value and then with the fixed file extension string (in our example ' . jpg'). In a still further embodiment, illustrated in Fig.4, the same external file may be used more than once, in order to render different features within the document. By varying the parameters of the image rendering procedure, one and the same image may be rendered once as a real-size color photograph and then again, in the background, as a light "ghost image." Depending on the PostScript level and other characteristics of the RIP, the procedure may be made even faster by reading image data into a "reusable stream."

The data file used according to the invention may be any flat ASCII text file, such as a delimited of a fixed space file. For the example illustrated in Figs. 1-4, the data may have the lowing structure: f_01 f_02 f_03 f_04 f_05 f_06 Doe John 123 Main Street Mainville 98765 Utopia 12345678 Doe Jane 234 First Ave. Smallville 87654 Utopia 12345432

In the case of a delimited file, an appropriate delimiter will be assigned, for example the " | " (pipe) character, or some other character or combination of characters that cannot be a part of the record. In both delimited and fixed space files, the carriage return character (<CR>, ASCII value 013) will serve as a delimiter between records. Using our example, the delimited text would be as follows: Doe]John|123 Main Street IMainville 98765 | Utopia | 12345678 | 02-JUL-02 | DJ123456|M| s: /utopia/assets/images/dj 123456. jpg<CR>. Doe|Jane|234 First Ave . | S allville 87654 |Utopia | 12345432 | 02-JUL-02 I DJ123454 I F| s : /utopia/assets/images/dj 123454. jpg<CR> When the invention is implemented using PostScript as the PDL, the procedure for parsing a delimited or fixed space text file, while definitely possible, may prove to be less efficient. It is more convenient to provide each field as a separate line of the data file and to employ the PostScript readline operator. According to a preferred embodiment of the present invention, therefore, the data file would have the following format: Doe John 123 Main Street Mainville 98765 Utopia 12345678 02-JUL-02 DJ123456 M s : /utopia/assets/images/dj 123456. jpg <EOR> Doe ^' Jane 234 Firs t Ave . Smallvil le 87654 Utopia 12345432 02-JUL-02 DJ123454 F s : /utopia/assets/images/dj 123454 . jpg <EOR> <EOF> It should be noted that the readline operator does not read the <CR> character into the string, which enables direct reading of the string into a corresponding variable. The <EOR> line serves as a record delimiter, while <EOF> indicates the end of data file. -Let the path/filename of the data file be, for example, 's : /utopia/j obOOl ..cit.' The procedure may now look as follows: /datafile ( s : /utopia/j obOOl . cit ) def /fnameO datafile (r) file def % Open data file /countf nn 0 def % initiali ze line count /ls_eof 5 string def /countf__nn 0 def % reset line count { /sr 255 string def /countf_nn countf_nn 1 add def /sr fnameO sr readline pop def sr (<eof>) eq {/ls_eof (<eof>) def exit} if countf nn 1 eq {- /^•f-__0-1- sr def" if countf_nn 2 eq { /f_02 sr def if countf_nn 3 eq { /f_03 sr def if co.untf_nn 4 eq { /f_04 sr def if countf_nn 5 eq { /f__05 sr def if countf_nn 6 eq { /f_06 sr def if countf_nn 7 eq ( /f_07 sr def if countf_nn 8 eq { /f_08 sr def if countf_nn 9 eq { /f_09 sr def if countf_nn 10 eq { /f_10 sr def if ^' sr (<eor>) eq {proc_01 exit} if } loop

The is_eof variable is introduced to enable the. RIP to exit at the end of data file, as will be discussed below. The proc_0l generally denotes a procedure for rendering one instance of the complete document. It is important to note that the data file remains open. When rendering the next instance of the document, the counter countf_nn is reset and the line following the last <EOR> becomes the new line 1. A reader skilled in the art of variable printing may remark that format of the data file according to the preferred embodiment of this invention is not standard and can not be obtained automatically from conventional database or spreadsheet applications (which usually allow for exporting comma- or tab-delimited files). It should be noted, however, that the data file according to this invention is primarily meant to be generated, directly from data sources, by a specialized variable printing application developed by authors of the present invention.

According to the second aspect, this invention provides a method for a dynamic, in-RIP imposition of variable documents on a column, row, page and job level. In prior art solutions, either the complete imposed layout is sent to the RIP, or the imposition rules have to be

^• applied to already defined pages. The present invention provides a significant degree of flexibility and streamlines the workflow by rendering another pre-processing operation unnecessary. Upon the commencement of the ripping process, the PDL code is processed in a series of loops, following dynamically assigned imposition and pagination rules, as illustrated in Fig. 5. Execution ends when all the records in the data file have been exhausted, or when a predetermined number of pages has been reached.

The details of the in-RIP imposition method will be discussed with reference to Fig. 5 and the following example of the PDL code:

/XPAGE 45.6 def % set general position of first /YPAGE 577.65 def % document on the page /xdoc XPAGE def % set position of first document /ydoc YPAGE def % on first page /XINCREMENT 269.8 def % move position of subsequent /YINCREMENT -174 def % docs on the same page /PAGE_NUM 100 def % max. number of pages in the job /ROW_NUM 4 def % number of rows per column I COL NUM 2 def % number of documents per row job_proc /page_count 1 def initialize page counter { page loop begins ls_eof (<eof>) eq {exit} if ' exit at end of data file page_count PAGE_NUM gt {exit} if i exit at max. no. of pages page_proc /c l_count 0 def % initialize column counter { % column loop begins /col_count col_count 1 add def % increment column counter ls_eof (<eof>) eq {exit} if % exit at end of data file col_count CO _NUM gt {exit} if % exit at set no. of columns /row count 0 def % initialize row counter % row loop begins /row_count row_count 1 add def % increment row counter row_count ROW_NUM gt {exit} if % exit at set no. of rows ls_eof (<eof>) eq {exit} if % exit at end of data file main_proc /ydoc ydoc YINCREMENT add def % go to next y position } loop % row loop ends /xdoc xdoc XINCREMENT add def % go to next x position /ydoc YPAGE def % reset document y position } loop % column loop ends showpage /page_count page_count 1 add def % increment page counter grestore /xdoc XPAGE def % reset the position of /ydoc YPAGE def % first doc on next page loop % page loop ends fna eO closefile close data file The is_eof variable is present in each of the nested loops. As already mentioned, its function is to allow the RIP to exit when the <EOF> line in the data file is reached. According to a preferred embodiment, of this invention, this means that the ripping process is completely data-driven - it commences without a pre-set number of pages and proceeds for as long as there are records to be printed. The PAGE_NUM constant, set in this example to 100, should be understood as a safety feature which will limit the job size and'prevent overloading of the image memory in the case of erroneous generation of an excessively long data file. Constants XPAGE and YPAGE define the position of the first document on the page, while variables xdoc and ydoc, initially set to XPAGE and YPAGE, increment their values as successive documents are rendered (by YINCREMENT for the successive row and by XINCREMENT for the successive column), and are reset to XPAGE and YPAGE values at the beginning of each new page. In this example, as illustrated in Fig. 5, the top left document is printed first, while the bottom right document is printed last. It will be obvious that this order may be readily changed by changing the values of appropriate constants, or by nesting the column loop within the row loop rather than the other way around. Constants RO _NUM and CO _NUM define the number of rows and columns and, when multiplied, define the number of documents to be printed on each page. By defining the imposition pattern in a dynamic manner, it is possible to utilize the same PDL code, in conjunction with the same data file, in a completely device-independent way. Thus, for example, if documents to be printed are card-sized, 4 rows by 2 columns setting will be used to output 8 cards on a sheet using a regular desktop printer, 7 rows by 3 columns will produce 21 cards on tabloid format, printing on a web-fed Xeikon press will allow 5 columns by almost any number of rows, etc. To allow for such flexibility, according to a preferred embodiment of the invention, any bounding boxes and/or clipping paths will generally be defined on the individual document level only, i.e., within the main_proc procedure in the above listing (main _proc will typically include reading one set of values from the data file plus the proc_0l procedure mentioned above). On the page level, RIP will preferably be allowed to utilize default device settings. However, as will be discussed below, this will not always be the case and therefore should not be considered a limitation of the present invention.

In the embodiments of the invention presented so far, fixed and variable page elements were discussed only on the level of an individual document. According to a further embodiment of the invention, however, the fixed and variable page elements may also be defined on the row, column, page and job levels. Thus, for example, Fig. 5 illustrates a page with a "job header" and a "page header." The job header and page header may be defined as, respectively, fixed ^'and variable elements within a procedure generally designated as page_proc in the PDL listing above. Although illustrated as a "header," elements defined in the page_proc may be rendered anywhere on the page and may include anything from titles and page numbering to registration or crop marks, pitches for foil stamping or die cutting, etc. The page-level elements may require the use of bounding boxes or clipping paths, thus departing from the above preferred solution. Optionally, the procedure generally designated as job_proc may be added if, for example, one or more special pages have to be printed at the beginning or at the end of the job. Generally, therefore, the method of the present invention provides for multiple levels of variability, at least on document, row, column, page and job levels. In addition, a person skilled in the art will appreciate that rendering of variable elements may be driven from a single data file, or that a separate data file may be provided for each level.

According to the third aspect of the present invention, rendering of variable page elements includes an in-.RIP, algorithmic generation of various machine-readable elements, such as OCR (optical character recognition) zones, bar codes, etc. In addition, certain projects will require manipulation of source data before rendering, for example conversion between lowercase and uppercase, replacing or suppressing certain characters, changing the format of dates, truncating or padding character strings to achieve a pre-determined length, etc. Such manipulation, according to the invention, may also be accomplished at RIP time, using algorithms built into the PDL code.

In conventional variable printing applications, various machine-readable features must generally be generated in a separate process, and incorporated (or referenced) in the PDL output as relatively large graphic files. As a consequence, processing, storage, network traffic and ripping requirements may increase to unacceptable levels. On the other hand, in security document industry, such elements often represent valuable security features and creating them as separate files opens a number of possibilities for misuse. The present invention overcomes Both problems by incorporating appropriate algorithms into the PDL code and rendering the elements directly into the image memory.

The following PDL listing, defining a simplified procedure for rendering Code 128 bar code, provides an example of several above-mentioned features of this aspect of the invention.

/ f_06bar 9 string def % temp barcode variable f_06 length 9 le % truncate f_06 if too long { /f_06bar f _06 def } { /i 0 def { f_06bar i f_06 i get put /i i 1 add def i 8 gt { exit } if } loop } ifelse /spacl 32 def /spac2 194 def % change lower to uppercase and % replace ' space ' with ASCII 194 /i 0 def /len f_06bar length 1 sub def { f_06bar i get 97 ge f_06bar i get 122 le and { f_06bar i f_06bar i get 32 sub put } if f__06bar i get spacl eq { f_06bar i spac2 put } if /i i 1 add def i len gt { exit } i f loop % calculate modulo 103 checkdigit /i 0 def /end val 104 def % initialize check digit variable % with ASCII value of start - 100 /wgh 1 def % initialize weighing multiplier { /cur_val 0 def f_06bar i get 134 le {/cur_val f_06bar i get 32 sub cvi def) if f_06bar i get 134 gt {/cur_val f_06bar i get 100 sub cvi def} if f_06bar i get 194 eq {/cur_val 0 def} if /cur_val cur_val wgh mul def /chd_^val chd_val cur_val add def /i i 1 add def /wgh wgh 1 add def i len gt { exit } if } loop /chd_val chd_val 103 mod def /chd_num 0 def chd_val 94 le chd_val 0 gt and { /chd_num chd_val 32 add def } i f chd_val 94 gt { /chd_num chd_val 100 add def } if chd_val 0 eq { /chd_num 194 def } if /barcode f_06bar length 3 add string def barcode string = barcode 0 204 put start symbol + barcode 1 f_06bar putinterval temp variable + barcode f_06bar length 1 add chd_num put check digit + barcode f_06bar length 2 add 206 put stop symbol /AdvC128d findfont 16 scalefont setfont 0 setgray 100 '500 moveto barcode show

In this example, illustrated in Fig. 6, the card number variable (f_06 in Fig. 1) is rendered as a Code 128 bar code. Any other variable element, combination of variable elements, or combination of fixed and variable elements, may be used instead.

A review of standard Code 128 specification is advised if a complete understanding of the algorithm is sought. For the purposes of this specification, however, it will suffice to say that a start code, stop code and an appropriately calculated check digit are rendered together with the f_06bar string, using the AdvC128d bar code font (available from ID Automation Inc.). Most other linear bar codes are available as fonts, while 2D bar codes (such as PDF417, DataMatrix, Superscript, etc.) may also be rendered in a similar, although slightly more complex fashion. Other features illustrated in the above example include truncating the character string, case conversion and character replacement.

According to the invention, fixed elements, or repeatable variable elements of the document layout, may be handled in a manner which will take advantage of available device-specific RIP and post-RIP features. An overview of these features is presented in the prior art section. The first, least efficient but most device-independent embodiment comprises defining one or more fixed elements, or repeated variable elements, within one or more PostScript forms. Most contemporary RIPs are able to save the result of form processing in a memory cache. The following example defines a form comprised of a two-color background and a simple single-color image:

10 diet begin /FormType 1 def /PaintProc l Pop. .656 .641 .410 setrgbcolor o. "3 panel 1 0 0 248.6 119 rectfill .438 .570 .680 setrgbcolor o. panel 2 0 119 248.6 158.7 rectfill 0 setgray % image 24 122 translate 32 31.787 scale 300 298 false [300 0 0 -298 0 298] { <

%% image binary goes here %%

>} imagemask } bind def /BBox [0 0 248.6 158 .7] def /Matrix [1 0 0 1 0 0] def currentdict end /BkgrndForm exch def

Most RIPs will typically be able to handle the above form provided that image binary does not exceed 64 Kbytes. Execution of one or more such forms will normally be a part of proc 01.

The second embodiment takes advantage of the post-RIP "collating," available with Xeikon- based output devices. In this embodiment, two PDL files will be generated. Both will be interpreted in a series of nested loops as described above, but the "master page" file will include within its main procedure only the background layer of fixed elements and will have the PAGE_NUM constant set to 1. If the background layer includes repeated variable elements, and if the number of possible combinations thereof is reasonably small, more than one -"master page" may be generated. In variable printing terminology, such master pages will be called "picked masters." The "master page" PDL files will generally be interpreted without a corresponding data file.

The variable PDL file will include within its main procedure rendering of non-repeated variable elements as described above, as well as any fixed and/or repeated elements which are to be rendered in the foreground layer (i.e., "on top" of variable elements). Those familiar with Xeikon printing will appreciate that a separate control file comprising instructions for the collator - the "book ticket" file - will be generated as well. In the third embodiment, fixed and repeated elements may be cashed as ripped objects in the image memory of the output device. As mentioned before, this feature is available in proprietary solutions provided e.g., by Creo-Scitex or Indigo, as well as with more recent versions of Xeikon collator. In all these solutions a control file, analogous to the above- mentioned "book ticket" file, provides instructions for the print-time merging of elements. The procedures vary from vendor to vendor, and the present invention is not limited to any specific solution. It should be noted, however, that standardization of these procedures is well under way. ^•• The new standard, likely to be adopted by digital printing industry, is the XML-based PPML (Personalized Print Markup Language), currently in Version 2.0. Due to its flexibility, the method of the present invention if equipped to take full advantage of this new standard.

In the fourth and final aspect, the present invention comprises a system for in-RIP processing and printing of variable documents. Generally, the system comprises a software application capable of generating the PDL files and the data files according to the present invention; a raster image processor (RIP), provided with a direct access to said PDL files and data files, capable of processing said PDL files in conjunction with said data files; and a digital output device connected to said RIP and capable of printing documents generated according to the present invention. The software application is provided with a direct access to a data source, such as database. If the variable documents comprise external digital assets (e.g., photographs), the RIP is additionally provided with a direct access to the storage of such digital assets. In one embodiment, shown in Fig. 7, the software application generates one PDL file and at least one data file. The PDL file is passed to the RIP to be interpreted, rendered into the image memory and printed on the output device, typically a desktop printer. The data file(s) and digital assets storage must be directly accessible to the RIP. If the desktop printer is a PostScript printer, the RIP host and image memory storage will generally form a part of the device. If the desktop printer is a Windows printer, the PDL output will be passed to a Windows PostScript interpreter such as Adobe's Acrobat Distiller or Aladdin Enterprises' GhostScript. The interpreter (serving as the RIP) will generally reside on the same host, and will use the • Windows spooler as the image memory. The data file(s) and digital assets storage must be directly accessible to the interpreter. Although the use of a Windows printer may be advantageous in small, self-contained systems, it should be noted that processing would be much slower and limited in capacity. The system featuring a fully enabled PostScript printer, therefore, represents a preferred embodiment of the invention. In another embodiment, shown in Fig. 8, the software application generates at least one PDL file, at least one data file, and a control file. If more than one PDL files are generated, they will generally represent one or more "master" PDL files and one "variable" PDL file. The PDL files are passed to the RIP, which generally resides on a dedicated host. The data file(s) and digital assets storage must be directly accessible to the RIP host.

The job is rendered into a fast image memory, for example a PrintStreamer (manufactured by Barco Graphics and available in certain configurations of Xeikon press). At print time, the control file is passed to the collator (a part of the output device firmware), which accesses the image memory, composes the final pages and sends them to the digital press.

In yet another embodiment, shown in Fig. 9, the software application generates one PDL file, at least one data file, and a control file. The fixed and repeated variable elements in the PDL file are appropriately labeled (e.g., in Indigo terminology, assigned to a "channel"). The RIP, which generally resides on a dedicated host, interprets the PDL file and renders the job into the fast image memory. The data file(s) and digital assets storage must be directly accessible to the RIP host. In this embodiment, the image memory may again be the PrintStreamer, or any other fast storage (e.g., a RAID 0 system) which generally forms a part of the output device host. At print time, the control file is passed to a merge application (typically a part of the output device firmware), which accesses the image memory, composes the final pages and sends them to the digital press.

The present invention has been described with reference to embodiments which are believed to be preferred and most advantageous in view of currently available technologies. The invention, however, is not to be limited to the disclosed embodiments. It will be apparent to a person skilled in the art that numerous variations or alternative solutions may be devised without departing from the spirit and the scope of the present invention, as disclosed and defined in the appended claims.

Claims

What is claimed is: 1. A method for in-RIP processing of variable documents, wherein the document layout comprises at least one fixed element and at least one variable element, comprising: generating at least one page description language (PDL) file defining said fixed and variable elements, wherein the variable elements are defined as PDL variables, generating at least one data file defining at least one instance of values of said PDL variables, and processing said at least one PDL file in a raster image processor (RIP) so as to assign said at least one instance of values to said PDL variables, and to render at least one instance of the variable document into the image memory of a digital output device.

A method of Claim 1, wherein said fixed and variable elements of the document layout comprise graphic elements such as text, line-art, and images.

3. A method of Claim 1, wherein a PDL variable is assigned a value by concatenating values of at least two PDL variables.

4. A method of Claim 1, wherein a PDL variable is assigned a value by concatenating value of at least one PDL variable with a fixed string defined in the PDL file.

A method of Claim 1 , wherein a PDL variable is assigned a value by transforming value of at least one PDL variable according to an algorithm comprised in the PDL file.

A method of Claim 5, wherein said transformation is selected from a group comprising, without limitation, case conversion, character suppression or replacement, date format conversion, truncating, padding, and generation of machine-readable elements.

7. A method of Claim 1, wherein one PDL variable defines multiple elements of the document layout.

A method of Claim 1, wherein said processing comprises rendering a variable element as text of a pre-defined typeface and size..

A method of Claim 1, wherein said processing comprises rendering a variable element in a machine-readable form.

10. A method of Claim 1, wherein the PDL variable comprises a path and/or filename of an external graphic element to be rendered during processing of said at least one instance of the variable document.

11. A method for in-RIP processing of variable documents, wherein the document layout comprises at least one fixed element and at least one variable element, comprising: generating at least one PDL file defining said fixed and variable elements, wherein the variable elements are defined as PDL variables, generating • at least one data file defining multiple instances of values of said PDL variables, and processing said at least one PDL file in a RIP, so as to assign said multiple instances of values to said PDL variables, and to render said multiple instances of the variable document into the image memory of a digital output device.

12. A method of Claim 11, wherein said at least one PDL file comprises at least one loop which is processed to render multiple instances of the variable document.

13. A method of Claim 12, wherein the loop is processed until all the instances of the variable document are rendered.

14. A method of Claim 12, wherein each instance of the variable document is rendered into the image memory of the digital output device as a separate page.

15. A method of Claim 11, wherein said at least one PDL file comprises a series of nested loops which are processed to render multiple instances of the variable document.

16. A method of Claim 15, wherein the series of nested loops is processed until all the instances of the variable document are rendered.

17. A method of Claim 16, wherein each page rendered into the image memory of the digital output device comprises multiple instances of the variable document.

18. A method of Claim 17, wherein each page is rendered by processing the series of nested loops so as to position the multiple instances of the variable document in rows and columns, the number of rows and columns being assigned to fit the page size of the digital output device.

19. A method for in-RIP processing of pages comprising multiple instances of a variable document, wherein each instance of the variable document comprises at least one fixed element and at least one variable element, comprising: generating at least one PDL file defining said fixed and variable document elements, and at least one fixed and one variable page element, wherein the variable elements are defined as PDL variables, said PDL file comprising a series of nested loops for positioning said multiple instances of the variable document in rows and columns, generating at least one data file defining multiple instances of values of said PDL variables, and processing said at least one PDL file in a RIP so as to assign said multiple instances of values to said PDL variables, and to render at least one page comprising multiple instances of the variable document into the image memory of a digital output device.

20. A method of Claim 19, wherein the series of nested loops is processed until all the instances of the variable document are rendered.

21. A method of Claim 19, wherein at least two data files are generated, one data file defining multiple instances of PDL variable values defining variable document elements, and the other data file defining multiple instances of PDL variable values defining variable page elements.

22. A method of Claim 19, wherein said at least one PDL file, in addition to pages comprising multiple instances of the variable document, defines at least one additional page.

23. A method for in-RIP processing of variable documents, wherein the document layout comprises at least one fixed element and at least one variable element, comprising: generating at least one PDL file defining said fixed and variable elements, wherein the variable elements are defined as PDL variables, generating at least one data file defining at least one instance of values of said variable elements, processing said at least one PDL file in a RIP, to render the fixed elements of the document layout into the image memory of a digital output device, processing said at least one PDL file in. a RIP so as to assign said at least one instance of values to said PDL variables, and to render said at least one instance of the variable elements of the document layout into the image memory of a digital output device, said digital output device being capable of merging said fixed and variable elements of the rendered document layout.

24. A method of Claim 23, further comprising generating a control file, said control file providing instructions for merging said fixed and variable elements of the document layout.

25. A method of Claim 23, wherein said fixed elements of the document layout are rendered into the image memory as a complete page layout.

26. A method of Claim 23, wherein said fixed elements of the document layout are rendered into the image memory as one or more dynamic page elements.

27. A method for in-RIP processing of variable documents, wherein the document layout comprises at least one fixed element and at least one variable element, comprising: generating at least one PDL file defining said fixed elements, generating at least one PDL file defining said variable elements, wherein the variable elements are defined as PDL variables, generating at least one data file defining at least one instance of values of said variable elements, •processing said at least one PDL file defining fixed elements in a RIP, to render the fixed elements of the document layout into the image memory of a digital output device, processing said at least one PDL file defining variable elements in a RIP so as to assign said at least one instance of values to said PDL variables, and to render said at least one instance of the variable elements of the document layout into the image memory of a digital output device, said digital output device being capable of merging said fixed and variable elements of the rendered document layout.

28. A method of Claim 27, further comprising generating a control file, said control file providing instructions for merging said fixed and variable elements of the document layout.

29. A method of Claim 27, wherein said fixed elements of the document layout are rendered into the image memory as one or more complete page layouts.

30. A method of Claim 27, wherein said fixed elements of the document layout are rendered into the image memory as one or more dynamic page elements.

31. A system for in-RIP processing and printing of variable documents, wherein the document layout comprises at least one fixed element and at least one variable element, comprising: a software application capable of generating at least one PDL file defining said fixed and variable elements, wherein the variable elements are defined as PDL variables, and at least one data file defining values of said PDL variables, a raster image processor (RIP) provided with access to said at least one PDL file and at least one data file, said RIP being capable of processing said PDL file so as to assign said values to said PDL variables, and to render the variable document into the image memory of a digital output device, and a digital output device capable of printing said documents.

32. A system of Claim 31, wherein at least one PDL variable comprises a path and/or filename of an external graphic element, and wherein said RIP is further provided with access to the storage of such external graphic elements.

33. A system of Claim 31, wherein said RIP is capable of processing said at least one PDL file to render the fixed elements of the document layout into the image memory of a digital output device separately from rendering the variable elements of the document layout, wherein said digital output device is further capable of merging said fixed and variable elements of the document layout, and wherein said software application is further capable of generating a control file, said control file providing instructions to the digital output device for merging said fixed and variable elements of the document layout.

34. A system of Claim 33, wherein said RIP is capable of rendering the fixed elements into the image memory as one or more complete page layouts.

35. A system of Claim 33, wherein said RIP is capable of rendering the fixed elements into the image memory as one or more dynamic page elements.