PPML (Personalized Print Markup Language)   Table of contents   Indexes   Selection and utilization of metadata from news articles
 Content  
Format
 PPML 
 Printing 
Publishing
RIP
Ticket
 XML 
 digital printing 
imposition
personalized printing
variable data printing
 

Book Ticket Files & imposition templates for variable data printing

 fundamentals for PPML
De Bosschere, Dirk
 
 Dirk  De Bosschere
 Systems Development Manager
 Barco Graphics – Digital Printing Systems
 Belgium 
Gent
Barco Graphics – Digital Printing Systems,  Tramstraat 69
Gent   B-9052 Belgium
Phone: +32-9-216.9212 Fax: +32-9-216.9825 email: dirk.debosschere@barco.com web site: www.barco.com/graphics
 Biography
 Dirk De Bosschere - Dirk is Systems Development Manager of the Digital Printing Systems division at Barco, a leading provider of systems and products for the Graphic Arts Industry. Dirk started as a Software Engineer for DISC in 1979, long before it became Barco Graphics. In his early years, Dirk refined his abilities to identify specialized user requirements in the Graphic Arts market place. Dirk defined various product specifications, and played a key role in developing and introducing successful products (DigiLabel, Mercator, …) into the market. In 1990, Dirk left Barco to pursue further experience at the ’user side of the fence’, managing production at a medium size pre-press service house. Early 1995, he returned to Barco, reinforced with an invaluable amount of customer-experience. In his current assignment, Dirk is fully involved with Digital and Personalized Printing. securing Barco’s existing reputation of building innovative solutions and products for Personalized and Digital Printing. Dirk holds a Master of Science degree in Electrical Engineering and a Master of Science degree in Industrial Management, both from the University of Gent, Belgium.
 Abstract
 Long before the PPML standard (Personalized Printing Markup Language) was built, Barco understood the appropriateness for using XML in describing personalized documents and how pages are to be 'imposed' on digital presses. This presentation amplifies on the 'Book Ticket Files' and 'Imposition Templates', and their concepts that contributed to the PPML standard.
 

Introduction – variable data printing

 In the publishing domain, there is a very strong trend towards personalization. Today’s documents, whether it be simple letters or leaflets, or catalogs comprising several pages are really targeted at a ‘market of one’.
 While the goal is obviously to increase the relevance of the information presented to the end-user, the same pieces of information will typically be used again and again, but in a different combination. Each end-user has the impression that the resulting document was built ‘from scratch’ for him and nobody else.
 With the arrival of the digital color printing machines, the technology is now available to make every single printed page unique. Not just the name, a number or some lines of text can be varied, but also graphical information, pictures, layout, full columns of text, etc.
 
Variable data printing
 The same graphical objects are used in different combinations to produce personalized documents.
 

The digital printing challenge

 Digital printing presses have turned the world upside down. While the traditional ‘print server’ was used to relief the client’s computer from waiting for a slow printer (‘spooling’), today’s digital presses are too fast for the applications and the RIPs (Raster Image Processors) to feed them at nominal speed. That’s how the ‘press server’ concept was born. The press server’s only task consists in keeping the (digital) press running at nominal speed.
 

PrintStreamer – a press server

 Barco’s ‘press server’ is called “PrintStreamer”, and a closer look at it’s architecture will reveal how Book Ticket Files and Imposition Templates found their origin.
 
PrintStreamer architecture & concept
 Assembling ripped and compressed objects at nominal printing speed.
 

PrintStreamer – architecture & concept

 The PrintStreamer (see ) is based on a standard NT computer system combined with dedicated hardware to expand the data on the digital press. Objects are ripped by the RIP and are sent to the NT file system in compressed format. The “data management” software keeps track of the changes of the different objects on the PrintStreamer. A Book Ticket File (XML!) describes the relationship between the different objects (pictures, texts, logos, …) that make up the different pages of a job. This description is parsed by the “print and sheet control” software, creating the assembly commands to merge the different objects onto the defined printing sheets. The “merge” software executes the merge commands and creates the final pages. Imposition Templates (XML!) drive the “imposition” software that merges the pages together to a full print sheet and passes the assembled sheets in compressed format to the expansion boards. All operations are performed on the compressed format to reduce the bandwidth needs in the NT system.
 PrintStreamer can store multiple thousands of ripped color objects and is capable of merging 100 % variable data at nominal printing speed. The required aggregate data rate is over 100 MB per second (for a Xeikon DCP-50D).
 

PrintStreamer – open interfaces

 PrintStreamer fits in between a RIP and a Digital Press (see ).
 
PrintStreamer open interfaces
 PrintStreamer in between a RIP and a Digital Press.
 An industry standard interface guarantees that PrintStreamer can easily be integrated into different digital printing press architectures. PrintStreamer is also open towards different front-ends: a documented API describes the interface into the PrintStreamer in order for RIP vendors to be able to integrate their RIP-technology. This makes the PrintStreamer accessible for PostScript, PDF, AFP, IPDS or other dedicated page description languages. But together with the RIP sending the actual content data, we need a second ‘control’ channel: Book Ticket Files.
 

Book Ticket Files

 It becomes clear from the above that Book Ticket Files came into being through the need for an efficient and flexible way of describing the assembly of graphical objects into printable pages. This description is available for industry partners to interface their applications, in order to take benefit of the PrintStreamer high performance collating and merging capabilities.
 

Book Tickets – what they contain

 

Structure data

 
  • Jobs built from Instance Documents
    •  
  • Instance Documents built from Pages
     
  • A variable number of pages per instance document!

    •  

    Layout data

     
  • Positioning of objects on Pages
    •  
  • Positioning of Pages on the output device (sheets)(through referencing Imposition Templates, see further)
    •  

    RIP & PRINT parameters

     
  • Screening
    •  
  • Number of copies
    •  
  • Production Marks (Control strip)
    •  
  • … (extensible)
    •  

    Post-Print parameters

     
  • Folding
    •  
  • Cutting
    •  
  • Finishing
    •  
  • … (extensible)
    •  

    Book Tickets – why XML?

     The very first Book Tickets were not encoded in XML. Soon numerous benefits became apparent in favor of XML:
     
  • Simple
    •  
  • Open
    •  
  • Platform-, vendor-, and language neutral
    •  
  • Extensible
    •  
  • Structure and Content format
    •  
  • Easier integration with web-applications
    •  The last mentioned benefit is the less obvious one, but no doubt a very important one! Indeed a majority of personalized printing projects are being conceived around an internet application. An XML-interface is most appropriate for a web-driven on-demand printing application!
     

    DTDs and parsing

     The DTD serves as ‘blueprint’, and is not used by a validating parser. At least not at the ‘consumer’ end of the Book Ticket. Book Ticket ‘producers’ must ensure well-formedness. The consumer can go ahead: non well-formedness results in a fatal error.
     Event driven parsing is the more appropriate, opposed to tree-based parsing (DOM). This is because of ‘streaming’ applications, where printing goes on and on for hours and even days. In these cases, the consumer cannot read the entire structure, before it begins processing.
     

    Book Ticket Files – an example?

     Showing an old-style Book Ticket File here would only bring along confusion, seen the fact that we choose for PPML nowadays (see further).
     

    Imposition templates

     

    Imposition in personalized printing

     It’s important to understand what imposition is and is not, especially in the context of personalized documents.
     
  • Imposition is the process of positioning page images on sheets of paper in the printer (or in a digital printing press), as part of the process of producing finished documents.
    •  
  • In addition to the page images, various marks can be added to the sheets, to aid in the production process. For instance, marks can be added to show where the paper should be folded or trimmed.
    •  
  • Imposition has no effect on the content of any individual page – it only affects where the pages are placed on a press sheet.
    •  In non-personalized printing, imposition is the placement of unchanging master pages onto a reproduction master, such as a printing plate. But in digital printing of personalized documents, there is no master – every copy is unique. Hence the need for a description of “signatures” that dynamically adapt to a stream of pages. Imposition is an integral part of the personalized digital printing workflow.
     

    Signatures

     A signature is a set of one or more pages from an Instance Document, printed on a single sheet of paper. The pages are arranged in a specific sequence, and are printed on one or both sides of the sheet.
     Here are some examples of frequently used signatures:
     
    Imposition examples
     Some very common imposition schemes.
     Each rectangle in an imposition layout represents one page of a document. Notice that no matter what size the page is, the imposition arrangement is a rectangular grid. Each box is called a “cell”, and it can have one page printed on the front (‘face up’) and a different page printed on the back of the sheet (‘face down’).
     The essence of imposition is found in the signature element. Here’s how the first example (at left in ) might be coded:
     
    <IMPOSITION Name="2UP">
<SIGNATURE Nrows="1" Ncols="2">
<CELL Row="1" Col="1" PageOrder="2" Face="Up" Rotation="0"/>
<CELL Row="1" Col="1" PageOrder="1" Face="Dn" Rotation="0"/>
<CELL Row="1" Col="2" PageOrder="3" Face="Up" Rotation="0"/>
<CELL Row="1" Col="2" PageOrder="4" Face="Dn" Rotation="0"/>
</SIGNATURE>
</IMPOSITION>
     

    Three dimensions!

     Distributing pages in row and columns of a signature is the easy part. In most cases, the pages of an instance document are to be distributed over several sheets, so there is a third dimension involved: through the stack of sheets. Here’s the most common example of an 8-page document that is printed on two 4-page signatures:
     
    Imposition over several sheets
     8-page document on two 4-page signatures.
     It is important to realize that there is no common rule for impositioning pages. It is up to the printer (customer) to decide on the sequence of stacking, folding and cutting. In the above example, the two printed sheets are first stacked, then folded, then cut. The assignment of pages to the signature cells would turn out COMPLETELY different if we would fold each sheet FIRST, then stack the folded sheets, and then cut the edges.
     

    Repeating signatures

     Step and repeat capabilities, in 3 dimensions, is of huge importance for digital printing. Take the example of printing business cards:
     
    Step and repeat
     A very common step and repeat schema (business cards).
     For this purpose, the imposition element can contain REPEAT elements, which may be nested around a signature element:
     
    <IMPOSITION Name="100x5 x 8-BusinessCard">
<REPEAT Direction="Stack" Action="Duplicate" Count="100">
<REPEAT Direction="Ver" Action="Increment" Count="8">
<REPEAT Direction="Hor" Action="Duplicate" Count="5">
<SIGNATURE Nrows="1" Ncols="1">
<CELL Row="1" Col="1" PageOrder="1" Face="Up" Rotation="0"/>
</SIGNATURE>
</REPEAT>
</REPEAT>
</REPEAT>
</IMPOSITION>
     
  • The required attribute Direction, with values “Ver”, “Hor”, and “Stack”, makes it possible to define separate repeat instructions in each direction.
    •  
  • The Action attribute determines which instance documents should be used to fill each repeated signature: “Duplicate” prints the same page image(s) in every signature, or “Increment” fills each successive signature with the next Instance Document.
    •  
  • The Count attribute in each <REPEAT> specifies how many signatures to repeat in each direction – in this example, 5 horizontally, 8 vertically, and 100 through the stack of sheets.
    •  Again, there are no common rules: if one need 500 business cards per person, the printer (customer) may print 500 sheets of 5x8 (different) business cards, or (as in the above example) 100 sheets where each business card is repeated 5 times. There are many parameters that determine his choice (document size, sheet/web size, finishing equipment, …).
     

    Imposition templates - XML

     Frequently used imposition schemes are stored on the file system as ‘Templates’. Notice from the examples above that these templates are quite generic, and automatically adapt to the actual page size (i.e. the same template can be used for A4 or letter-size pages).
     It should also be clear from the above examples that XML is extremely fit for encoding imposition schemes. The ability to have a variable number of cells in a signature, together with a variable number of (nested) repeats, accommodate the needs of the most demanding printer (customer).
     

    Personalized Print Markup Language (PPML)

     PPML is the brand-new XML-based industry standard for personalized digital printing, defined by an industry-wide consortium of 13 companies, including Barco. The specification is distributed free of charge at http://www.ppml.org/ . The standard is discussed in another paper from this conference. This paragraph handles the contribution of Book Ticket Files and Imposition Templates to PPML.
     

    PPML and Book Ticket Files

     Book Ticket Files served as an excellent starting point for PPML. However there were 3 issues beyond the existing scope of Book Ticket Files:
     
  • Heterogeneity of Content Data
    •  
  • Embedded Content
    •  
  • Hints on Content Reusability
    •  “Content Data” is source data (e.g. a picture, a text block, an EPS file) which may be placed on various Pages in various combinations of scaling, position, rotation, etc.
     

    Heterogeneity of content data

     In a PrintStreamer environment, all content data is pre-ripped to the PrintStreamer. So Book Ticket Files only know PrintStreamer objects.
     One of the key requirements of PPML was to accommodate any of the prevalent formats for content representation, such as PostScript, PDF, TIFF, etc.
     

    Embedded content

     Book Ticket Files only have references to external content data elements. Again this is because all content objects reside on the PrintStreamer. It was a requirement for PPML to support both embedded and external content.
     It is my personal belief that external references are preferable in a digital printing workflow. The later the ‘binding’, the more efficient/flexible. Moreover this allows for asynchronous delivery of content elements.
     Embedding content has some advantages for exchange and archival purposes. But perhaps the most useful application of embedded content is where numerous small content objects are used only once. Think for example of 100,000 direct mail documents where only the customer’s name and address changes. External content data elements require lots of small files here, and bring along a significant overhead.
     But embedding content in PPML also entailed some difficulties, because of the inadequacy of XML to include binary (non-XML) data as such.
     

    Hints on content reusability

     Although personalized printing gives the end-user the impression that the resulting document was built ‘from scratch’ for him and nobody else, the same pieces of information will typically be used again and again, but in a different combination. The ability to identify these ‘reusable objects’ while ‘consuming’ a PPML file was the single most important aspect of the new language. The lifetime and visibility of reusable objects is specified in PPML through a ‘Scope’ attribute, which can be Global, PPML, Job, Document or Page.
     Book Ticket Files had no need for such hints, simply because all PrintStreamer objects are reusable as such (PrintStreamer can be seen as one huge cache for ripped objects).
     

    PPML is welcome

     It is clear that the above mentioned differences must not be seen as shortcomings of Book Ticket Files. It was simply beyond the existing scope of Book Ticket Files in their PrintStreamer-only environment. Therefore we see PPML as the superior of both formats. It would fully satisfy Barco to see Book Ticket Files eventually being replaced by PPML.
     

    PPML and imposition templates

     It was our belief that PPML was incomplete without the capability to specify imposition. Barco Imposition Templates were an existing and proven technology before PPML. Barco made an all-out effort with respect to imposition. As with Book Ticket Files, we hope to eventually see PPML imposition as the one and only.
     

    Object management – XML for data exchange

     A “data management” module keeps track of all the objects that reside on the PrintStreamer.
     Here also, we are using XML as a data interchange format. The implementation is quite straightforward. An XML file is sent from the PrintStreamer to the client application. Object properties are encoded as attributes, and the properties of several objects are bundled into one XML file. The client application parses the XML message and may easily extract the ‘useful’ data.
     The decisive factor here is of course XML’s platform independent vocabulary. However, in this case we have chosen to provide our users with a C++ object library (SDK) on the appropriate platforms (NT, UNIX, and Macintosh), hereby making the usage of XML transparent. There are plans to uncover the XML-interface to the user. This may prove to be extremely useful because many of our users are developing XML-based web applications driving our PrintStreamer.
     

    XML for Job Tickets

     In the publishing and printing industry, there is an indisputable advance towards the usage of XML for ‘job tickets’. These are tickets that control the entire production process, up until the very ‘finishing’ or even the ‘delivery’ at the customer. Many standards were previously encoded in PostScript or PDF. Examples are CIP3’s Print Production Format (PPF) and Adobe’s Portable Job Ticket Format (PJTF). Many new emerging standards in this area made a determined choice for XML.
     Many companies like Barco follow this trend, using XML for their own job tickets. They use proprietary schemas until standards arise that can complement or take over the initial implementation. But nevertheless the tickets are XML!
     

    Conclusion

     XML has proven to be an excellent choice for describing Book Ticket Files and Imposition Templates. The acquired experience largely contributed to the development of PPML, the nascent standard for variable data printing. Barco has been pushing hard to make PPML be the appropriate format for variable data production printing. It would fully satisfy Barco to see Book Ticket Files and Imposition Templates eventually being replaced by PPML. On a smaller scale, Barco is using XML as a data-exchange format in numerous areas, such as object management and job tickets. XML has become permanent in Barco’s software solutions.
     Bibliography
     
    PPML The PPML Working Group, “ PPML, The Personalized Print Markup Language”, Functional Specification, March 2000, http://www.ppml.org/ .
    PPML (Personalized Print Markup Language)   Table of contents   Indexes   Selection and utilization of metadata from news articles