Dirk De Bosschere

1. Introduction – variable data printing
2. The digital printing challenge
3. PrintStreamer – a press server
   1. PrintStreamer – architecture & concept
   2. PrintStreamer – open interfaces
4. Book Ticket Files
   1. Book Tickets – what they contain
      1. Structure data
      2. Layout data
      3. RIP & PRINT parameters
      4. Post-Print parameters
   2. Book Tickets – why XML?
   3. DTDs and parsing
   4. Book Ticket Files – an example?
5. Imposition templates
   1. Imposition in personalized printing
   2. Signatures
   3. Three dimensions!
   4. Repeating signatures
   5. Imposition templates - XML
6. Personalized Print Markup Language (PPML)
   1. PPML and Book Ticket Files
      1. Heterogeneity of content data
      2. Embedded content
      3. Hints on content reusability
      4. PPML is welcome
   2. PPML and imposition templates
7. Object management – XML for data exchange
8. XML for Job Tickets
9. Conclusion
10. Bibliography

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.

Figure 1 . Variable data printing

Previous

Table of Contents

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.

Previous

Table of Contents

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.

Figure 2 . PrintStreamer architecture & concept

PrintStreamer – architecture & concept

The PrintStreamer (see Figure 2) 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 Figure 3).

Figure 3 . PrintStreamer open interfaces

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.

Previous

Table of Contents

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

Layout data

RIP & PRINT parameters

Post-Print parameters

Book Tickets – why XML?

The very first Book Tickets were not encoded in XML. Soon numerous benefits became apparent in favor of XML:

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).

Previous

Table of Contents

Imposition templates

Imposition in personalized printing

It’s important to understand what imposition is and is not, especially in the context of personalized documents.

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:

Figure 4 . Imposition examples

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 Figure 4) might be coded:

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:

Figure 5 . Imposition over several sheets

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:

Figure 6 . Step and repeat

For this purpose, the imposition element can contain REPEAT elements, which may be nested around a signature element:

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).

Previous

Table of Contents

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 [PPML] 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:

“Content Data” [PPML] 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.

Previous

Table of Contents

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.

Previous

Table of Contents

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!

Previous

Table of Contents

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.

Previous

Table of Contents

Bibliography

[PPML]

The PPML Working Group, “PPML, The Personalized Print Markup Language”, Functional Specification, March 2000, http://www.ppml.org/.

Previous

Table of Contents