Copyright Notice
The thesis "Job Definition Format – A Catalyst for Electronic Business Data Exchange
in the Commercial Printing Industry" is copyright 2003 by Catherine Dammann.
It may be downloaded for personal use provided that this copyright notice is not removed. It may not be used for commercial purposes, displayed on other websites or
used for any other purposes without prior written permission of the copyright holder.
© 2003 by Catherine Dammann.
University of Applied Sciences Bielefeld
Faculty for Business and Management Studies
Thesis in
Business Computer Science
Job Definition Format –
A Catalyst for Electronic Business Data Exchange
in the Commercial Printing Industry
Catherine Dammann
E-mail: cdammann@gmx.de
May 2003
© 2003 by Catherine Dammann.
II
Table of Contents
Figure Index .....................................................................................................IV
Table Index .......................................................................................................V
Abbreviation Index ...........................................................................................VI
1
Introduction............................................................................................... 1
1.1
The Problem .................................................................................... 1
1.2
Objective .......................................................................................... 1
1.3
Approach.......................................................................................... 2
2
The Commercial Printing Industry ............................................................ 3
2.1
Print on Demand .............................................................................. 5
2.2
Electronic Print Procurement ........................................................... 5
3
The Print Production Workflow ............................................................... 10
3.1
Workflow of a Print on Demand Job............................................... 10
3.1.1 Print Broker................................................................................ 10
3.1.2 Print Shop .................................................................................. 11
3.2
The Digital Workflow ...................................................................... 14
3.2.1 Data Exchange .......................................................................... 14
3.2.2 Current State ............................................................................. 16
3.2.3 Computer Integrated Printing..................................................... 18
4
Data Exchange Formats......................................................................... 20
4.1
Content Data Exchange ................................................................. 20
4.1.1 PostScript .................................................................................. 21
4.1.2 Portable Document Format........................................................ 22
4.2
Business Data Exchange ............................................................... 24
4.2.1 Proprietary Formats ................................................................... 25
4.2.2 Job Definition Format................................................................. 25
4.2.2.1 Predecessors ..................................................................... 27
4.2.2.2 The Extensible Markup Language...................................... 31
4.2.2.3 Specification ....................................................................... 36
4.2.2.4 Market Analysis of Implementation..................................... 44
5
Business Data Exchange with the Print Shop......................................... 52
5.1
Business Objects ........................................................................... 52
5.2
Product Specification ..................................................................... 54
5.2.1 Final Product.............................................................................. 55
5.2.1.1 Root Node .......................................................................... 55
5.2.1.2 Resources .......................................................................... 58
5.2.1.3 ResourceLinks.................................................................... 64
5.2.2 Product Components ................................................................. 64
© 2003 by Catherine Dammann.
III
5.3
Metadata ........................................................................................ 65
5.3.1 JDF Job Specification ................................................................ 65
5.3.2 PrintTalk..................................................................................... 68
5.3.2.1 Header and Request .......................................................... 68
5.3.2.2 Business Object Elements.................................................. 71
5.3.3 JDF BusinessInfo....................................................................... 75
6
Case Study............................................................................................. 76
6.1
MagentaSoft (Pty) Ltd. ................................................................... 76
6.1.1 The Company ............................................................................ 76
6.1.2 Electronic Print Procurement Application................................... 76
6.2
JDF/PrintTalk Implementation........................................................ 77
6.2.1 Request for Quote Data Definition ............................................. 77
6.2.2 Print Job “Business Cards” ........................................................ 79
6.2.2.1 Request for Quote in JDF/PrintTalk.................................... 79
6.2.2.2 Print Production.................................................................. 85
7
Summary and Outlook............................................................................ 87
Appendix ......................................................................................................... 90
A1 Questionnaire ........................................................................................ 91
A2 Answer Analysis of Questionnaire......................................................... 92
A3 Business Objects in JDF/PrintTalk ........................................................ 93
Bibliography .................................................................................................... 97
© 2003 by Catherine Dammann.
IV
Figure Index
Figure 1: Lifecycle of the Commercial Printing Industry .................................... 3
Figure 2: Mean Spending on Web Infrastructure in 2002 and Mean Planned
Spending on Web Infrastructure in 2003 within the Commercial
Printing Industry................................................................................. 4
Figure 3: Business Document Lifecycle ............................................................ 6
Figure 4: The Cost of Business Communication ............................................... 7
Figure 5: Job Cycle Time (in days) ................................................................... 8
Figure 6: Print on Demand Drives Print Market Growth (U.S.).......................... 9
Figure 7: Workflow of a Print on Demand Job at the Print Broker................... 11
Figure 8: Entire Workflow of a Print on Demand Job ...................................... 14
Figure 9: Print Shop Business Systems Integration with Web Infrastructure .. 16
Figure 10: Extending the Print Management System for Internet Business .... 19
Figure 11: PostScript as a Universal Format in Print Production .................... 21
Figure 12: Example of PostScript Commands ................................................ 21
Figure 13: The PDF-Workflow......................................................................... 23
Figure 14: Scope of JDF ................................................................................. 26
Figure 15: The PPF Workflow ......................................................................... 29
Figure 16: Building Blocks of a PPF File ......................................................... 29
Figure 17: Three Steps of Parsing an XML Document.................................... 32
Figure 18: The Importance of XML ................................................................. 33
Figure 19: XML Elements and Corresponding Tree Structure ........................ 35
Figure 20: JDF Tree Structure ........................................................................ 36
Figure 21: The JDF Node and its Child elements ........................................... 37
Figure 22: JDF Producer/Consumer Model .................................................... 38
Figure 23: A Hierarchical Tree of JDF Nodes ................................................. 41
Figure 24: A JDF Process Chain Linked by Input and Output Resources....... 41
Figure 25: JDF and JMF Workflow Interactions .............................................. 43
Figure 26: JDF Data Flow within Creo Networked Graphic Production........... 46
Figure 27: Commercial Print Industry Business Objects ................................. 54
Figure 28: Product Nodes in the JDF Tree Structure ...................................... 55
Figure 29: JDF Product Specification and JDF Job Specification ................... 66
Figure 30: A High Level View of the PrintTalk Structure ................................. 69
Figure 31: Extract of an Imposed PDF File ..................................................... 78
Figure 32: A Hierarchical View of the “Business Cards” Print Job .................. 79
Figure 33: The Original RFQ Text................................................................... 80
Figure 34: JDF System at a Print Shop........................................................... 85
© 2003 by Catherine Dammann.
V
Table Index
Table 1: JDF Child Elements .......................................................................... 38
Table 2: Relevant Optional Attributes of the JDF Generic Structure ............... 55
Table 3: Required Attributes of any JDF Node................................................ 56
Table 4: Required Attributes of the JDF Root Node........................................ 56
Table 5: Optional Attributes of any JDF Node................................................. 57
Table 6: Required Attributes of the Abstract Resource Element ..................... 58
Table 7: Required Attributes of a Component Resource................................. 59
Table 8: Relevant Required Attributes of the Abstract ResourceLink ............. 64
Table 9: Attributes of the PrintTalk Root Element ........................................... 69
Table 10: Elements of PrintTalk Header Element ........................................... 69
Table 11: Required Attributes of the Abstract Business Object ...................... 70
Table 12: Optional Attributes of the Abstract Business Object........................ 71
Table 13: Abstract Span Elements.................................................................. 72
Table 14: Attribute Set of Abstract Span Elements ......................................... 72
Table 15: Administrative Data of an RFQ ....................................................... 78
Table 16: Product Data of an RFQ.................................................................. 79
© 2003 by Catherine Dammann.
VI
Abbreviation Index
AG
API
ASCII
B2B
CAGR
CD-ROM
CFX
CIM
CIP
CIP3
Aktiengesellschaft (public company)
Application Programming Interface
American Standard Code for Information Interchange
Business-to-Business
Compound Annual Growth Rate
Compact Disc-Read Only Memory
Content File Exchange
Computer Integrated Manufacturing
Computer Integrated Printing
International Cooperation for Integration of Prepress, Press and
Postpress
CIP4
International Cooperation for Integration of Processes in Prepress, Press and Postpress
CMYK
Cyan, Magenta, Yellow, Key (Black)
CRM
Customer Relationship Management
CSS
Cascading Style Sheets
CSV
Comma Separated Value
cXML
Commerce Extensible Markup Language
DNS
Domain Name Service
DOM
Document Object Model
DTD
Document Type Definition
DTP
Desktop Publishing
E-commerce
Electronic commerce
EDI
Electronic Data Interchange
e.g.
exempli gratia (for example)
E-mail
Electronic mail
E-print procurement Electronic print procurement
E-procurement
Electronic procurement
EPS
Encapsulated PostScript
e-t-f
Electronic Ticket Format
Euprima
European Print Management Association
Fraunhofer IGD
Fraunhofer Institute for Computer Graphics
GER
Germany
GIF
Graphics Interchange Format
GmbH
Gesellschaft mit beschraenkter Haftung (limited liability company)
gsm
Grams per Square Metre
HTML
Hypertext Markup Language
HTTP
Hypertext Transfer Protocol
Ibid.
Ibidem
i.e.
id est (that is)
Ifra
INCA-FIEJ Research Association [INCA
International Newspaper Colour Association, FIEJ
Fédération
Internationale
des Editeurs de Journaux]
IMF
Ifra Message Format
Inc.
Incorporated
incl.
Inclusive
IOM
Inquiry and Order Management
ISDN
Integrated Services Digital Network
ISO
International Standards Organisation
© 2003 by Catherine Dammann.
VII
JDF
JDP
JITP
JMF
JPEG
JTP
LAN
Ltd.
MCC
MIME
MIS
No.
ODA
OEM
PC
PCL
PCX
PDF
PDL
PJTF
POD
PPF
PPML
PPS
pt
Pty
RFQ
RIP
ROI
SAX
SGML
SVG
TIFF
TWS
UK
UNESCO
URI
URL
US
VAT
VDP
W3C
XML
XSL
Job Definition Format
JDF Development Platform
Just-in-Time Printing
Job Messaging Format
Joint Photographic Experts Group
Job Ticket Processor
Local Area Network
Limited
Machine Control Console
Multipurpose Internet Mail Extensions
Management Information System
Number
Operating Data Acquisition
Original Equipment Manufacturer
Personal Computer
Printer Control Language
EProduction ECommerce Exchange Format
Portable Document Format
Page Description Language
Portable Job Ticket Format
Print on Demand
Print Production Format
Personalised Print Markup Language
Production Planning and Controlling System
Point
Proprietary
Request for Quote
Raster Image Processor
Return on Investment
Simple API for XML
Standard Generalized Markup Language
Scalable Vector Graphics
Tagged Image Format
Technical Workflow System
United Kingdom
United Nations Educational, Scientific and Cultural Organization
Uniform Resource Identifier
Uniform Resource Locator
United States
Value Added Tax
Variable Data Printing
World Wide Web Consortium
Extensible Markup Language
Extensible Stylesheet Language
© 2003 by Catherine Dammann.
1
1 Introduction
1.1 The Problem
Manufacturers, distributors, franchises, retailers and other enterprises have a large
demand for printed collateral. Price lists, product brochures, business cards and other
marketing collateral need to be regularly updated. Mass customisation of printed materials assists enterprises in effectively reaching their target markets. As the demand for
customised printed material increases, the need for efficiencies in print and print
procurement rises.
The commercial printing industry has adapted to these demands by providing services
focused on their clients needs. These include streamlining the print procurement process, the introduction of short run digital printing and the provision of services over the
Internet. Print on demand, coupled with digital workflows, empowers print buyers to
cost effectively procure print. Electronic print procurement (e-print procurement) software is available for enterprises to manage an online archive of their collateral and
submit it for print over the Internet. On the print shop side, efficiencies need to be introduced to speed the production of a print job. A print shop’s production consists of prepress (content preparation), press (actual print) and postpress (product finishing). Data
for functions such as print cost estimating, order processing, production planning, accounting, quality management and job tracking is double entered into non-integrated
management systems.
Lack of open standards between production and MIS lead to higher administrative
costs, slower information processing and capacity under utilization. Some processes
can be linked together via existing limited open data exchange formats, but the entire
print shop is often incapable of working together as a coherent unit.
1.2 Objective
Productivity gains can be attained through an automated workflow which links production and MIS through open data exchange standards. Job Definition Format (JDF) is an
open standard that describes an entire print job and all required processes for its production. JDF is based on the Extensible Markup Language (XML). A workflow can be
created that bridges the fragmented workflow elements of production and the functions
of MIS through JDF.
In conjunction with PrintTalk, the corresponding format for electronic commerce (ecommerce) data exchange, JDF can be used as a means for the exchange of business
© 2003 by Catherine Dammann.
1 Introduction
2
data between a print shop and an e-print procurement application. This thesis analyses
JDF as a suitable open format for electronic business data exchange in the commercial
printing industry.
1.3 Approach
Chapter 2 discusses the current market conditions in the commercial printing industry
and introduces Print on Demand (POD) and e-print procurement as emerging means to
remain competitive. The commercial printing industry comprises of print shops excluding desktop printing and photocopying business.
The current workflow of a print job placed by an enterprise via e-print procurement
software is described in chapter 3. This thesis refers to these high-volume customers
as print buyers (as opposed to low-volume private customers). The company offering
the software is referred to as print broker, independently representing a number of print
shops to the print buyer. The current workflow inefficiencies lead to the description of
the need for a digital workflow via open job ticket formats. A job ticket is a form or file
that contains all information for the production of a print job. Open formats are assumed when the specification is publicly available. Computer Integrated Printing as the
goal of a digital workflow is described, leading to the concept of integrating e-print procurement into the digital network of a print job.
Chapter 4 describes data exchange formats for the commercial printing industry. After
providing an overview of content data exchange for understanding the execution of a
print job, business data exchange formats are described. The JDF section introduces
the format's predecessors. An overview on XML is provided before JDF's fundamental
components are introduced. A market analysis points out the potential of the format.
Chapter 5 analyses a JDF/PrintTalk-based data exchange of business objects between
an e-print procurement application and the print shop.
The case study in chapter 6 has been created in collaboration with MagentaSoft (Pty)
Ltd., a South African-based print broker that provides e-print procurement to print buyers. The application is described and an implementation of JDF/PrintTalk is shown by
encoding a Request for Quote (RFQ) for a business cards print job.
This thesis is based on JDF specification 1.1 Revision A and PrintTalk specification
1.1. JDF elements are marked in font Courier, attributes in Courier italics and
their values in Arial italics.
© 2003 by Catherine Dammann.
3
2 The Commercial Printing Industry
The commercial printing industry faces a shift in market conditions and requirements.
The industry has moved from growth to maturity within the industry lifecycle
(see figure 1).
Figure 1: Lifecycle of the Commercial Printing Industry
Source (based on): Cap Ventures, Content on Demand, 2002, Page (P.) 5
“Industry maturity is reached when the market becomes saturated and growth slows.”1
This is characterised by flattening demand and overcapacities from the previous growth
phase resulting in a competitive market with decreasing prices.
Compounding this is new competition, coming from within the print buyer’s organisation. With the falling cost of digital printing equipment, it has become viable for larger
enterprises to print collateral on own printing devices. In addition, the number of outsourced prepress and finishing services is on the increase. “In the beginning of the
nineteen-nineties, the proprietory (!) and expensive phototypesetting and image processing stations were replaced by open, modular and configurable desktop publishing
(DTP) systems. DTP has enabled virtually everybody to be a publisher ever since.
Nowadays, many small print shops, ad agencies and graphic designers use the possi1
Cap Ventures, Content on Demand, 2002, P. 5.
© 2003 by Catherine Dammann.
2 The Commercial Printing Industry
4
bility of making digital masters and film lithos by themselves, a job which was reserved
to typesetters, repro shops and large printers in the past.”2
The demand for printed goods has changed to Just-in-Time Printing (JITP). “When
JITP is effectively implemented communication pieces are produced only when the
need arises.”3 Print buyers aim at stock reduction and market penetration with up-todate documents. Print shops face increasing job numbers with shorter run length (so
called short run jobs) with comparable set-up time for the printing device. Additionally,
JITP printing requires faster job turnaround.
In order to remain competitive, print shops have to identify areas in their print value-add
chain where productivity can be improved. Efficiency gain of new equipment has been
exploited. ”Nowadays, productivity can mainly be increased by means of new technologies, faster make-ready and networked digital workflows.”4 Technological innovations like the Internet need to be employed for establishing value-added products and
services to print buyers. Figure 2 shows results of a survey with 210 print shops on
their spending on web infrastructure in 2002 and planned spending in 2003.
Figure 2: Mean Spending on Web Infrastructure in 2002 and Mean Planned Spending on Web
Infrastructure in 2003 within the Commercial Printing Industry
Source: WhatTheyThink.com, Spending, 2002
In the survey, web infrastructure is defined as software or services for offering printing
and printing related services to print buyers via the Internet. The number of print shops
spending nothing will decrease from 34% in 2002 to 21.6% in 2003. While the number
of print shops spending $50 000 or more and $25 000 to $49 999 will drop from 12% to
11.3% (and 6% to 4.9% respectively), there will be higher spending in the segments up
2
INI-GraphicsNet, Printing, 2001, P. 3.
Smith, Traditional Printing, 2003.
4
INI-GraphicsNet, Printing, 2001, P. 5.
3
© 2003 by Catherine Dammann.
2 The Commercial Printing Industry
5
to $24 999. This shows a trend that print shops are beginning to recognise the need to
offer web-based services that are complementary to their core business.
2.1 Print on Demand
In the past decade, print shops have started printing on digital print devices. Digital
Printing offers efficiencies over traditional printing methods. It allows the introduction of
new value-add services.
Traditional printing with an offset press requires the creation of a printing plate for each
page. The plate transfers ink onto paper to produce the finished product. The digital
press directly processes text and images from a digital file to paper. This speeds up
production and eliminates costs associated with plate creation. It further eliminates ink
and paper wastage that occurs when adjusting an offset press.
Digital Printing has many benefits including the ability to manage text from a database
query with imagery on the printing device. This is known as Variable Data Printing
(VDP). VDP assists enterprises in effectively reaching their target markets by using
personalised marketing material for 'one-to-one-marketing'.
Digital Printing has been adopted by print shops, because it empowers them to effectively process short run jobs. “In fact when considering Print On (!) Demand (POD) and
Variable Data Printing (VDP), short runs now can mean a single piece, whether it is a
sell sheet or a single 200-page manual.”5 Digital Printing is often equated with POD,
since print shops are now able to offer JITP. “Print-on-demand is a process that supports the creation of printed matter. It provides what the customer wants, when the customer wants it and where the customer wants it – in other words, at or near the point of
use.”6
The Internet makes communication more efficient. Its prevalence in office environments changes business models in the commercial printing industry. Online services
accommodate the print buyer’s needs for JITP. POD is facilitated by employing software for e-print procurement.
2.2 Electronic Print Procurement
E-print procurement software empowers print buyers to order and handle print jobs
over the Internet. These applications implement the idea of e-commerce in the com-
5
6
Godwin, Digital Printing, 2002.
Cap Ventures, Content on Demand, 2002, P. 28.
© 2003 by Catherine Dammann.
2 The Commercial Printing Industry
6
mercial printing industry. “ 'E-Commerce' describes the trade between consumers and
merchants (business-to-consumer) or between business partners (business-tobusiness) via digital electronic media.”7
The e-print procurement software acts not only as an online intermediary between print
buyers and print shops, but provides services for facilitating processes in creation,
preparation and order management (see figure 3).
Figure 3: Business Document Lifecycle
Source (based on): Cap Ventures, Content on Demand, 2002, P. 16
E-print procurement assists in enabling cross-business procedures:
• The print procurement procedure - Print buyers are assisted in the creation and
preparation of documents for print. In addition, order submission through a centralised print procurement channel helps to achieve economies of scale for larger
companies. Digital asset management ensures the brand consistency, particularly
for enterprises with a distribution channel, such as franchises. The companies’
corporate identity standards are automatically enforced.
7
INI-GraphicsNet, Electronic Commerce, 1999, P. 3.
© 2003 by Catherine Dammann.
2 The Commercial Printing Industry
7
• The print procedure - The printer receives a print-ready file. The print-ready file
eliminates the entire labour and cost intensive prepress work as the file can be directly transferred to the press area. Precious sales time can be more efficiently
used for consulting on complex jobs as orders arriving through the e-print procurement channel are standardised.
Print buyers benefit from POD via e-print procurement with cost savings resulting from
inventory reduction. The former employed offset printing method caused over-purchase
due to economies of scale. In addition, waste is reduced by avoiding document obsolescence. Print buyers achieve a faster time to market through less preparation time.
Figure 4 shows that 6/7 of total document costs are process costs. The physical printing of the document only comprises 1/7 of the total cost.
Figure 4: The Cost of Business Communication
Source: Cap Ventures, Content on Demand, 2002, P. 18
Receiving print jobs from an e-print procurement application allows the print shop to
streamline repetitive orders with short make-ready time (see figure 5).
© 2003 by Catherine Dammann.
2 The Commercial Printing Industry
8
Figure 5: Job Cycle Time (in days)
Source: Institut fuer rationale Unternehmensfuehrung in der Druckindustrie e.V., Computergesteuerte Marionetten, 2001, P. 10
According to Cap Ventures, a provider of strategic information, consulting services and
market research for the print industry, the POD sector is expected to show stronger
growth than the traditional print industry. As shown in figure 6, the Compound Annual
Growth Rate (CAGR)8 of the POD industry is expected to rise by 20% until 2005
whereas the primary print industries' CAGR will increase by only 4%.
8
Definition CAGR by WebFinance Inc, http://www.investorwords.com/cgi-bin/getword.cgi?666
(05. Mar. 2003): „The year over year growth rate applied to an investment or other part of a
company's activities over a multiple-year period.”
© 2003 by Catherine Dammann.
2 The Commercial Printing Industry
9
Figure 6: Print on Demand Drives Print Market Growth (U.S.)
Source: Cap Ventures, PoD, 2002, P. 25
To benefit from this growth market, e-print procurement software needs to be fully integrated into the print shop's workflow. “E-commerce is an ecology-there are many systems interacting with each other, each functioning differently. Most people look at ecommerce as if it was technology, but it’s really process or workflow.”9
9
Jeffrey, E-commerce Evolves, 2000, citing: Hu, Robert, without further source indication.
© 2003 by Catherine Dammann.
10
3 The Print Production Workflow
Workflow is defined as “the automation of a business process, in whole or part, during
which documents, information or tasks are passed from one participant to another for
action, according to a set of procedural rules.”10 Workflow in the commercial printing
industry is often only equated with the digital workflow in the process-intense prepress
area. However, the print production workflow encompasses the automation of all processes needed for the completion of a print job. It affects the following areas at print
shops:
•
•
•
•
•
•
•
•
Estimation/Order Management
Production Planning
Prepress
Pressroom
Postpress
Delivery
Invoicing/Accounting
Data Analysis
“There is no such thing as a standard print workflow. In fact, printing is the ultimate
form of flexible manufacturing. This makes process automation quite a challenge for
our industry.”11
3.1 Workflow of a Print on Demand Job
This paragraph describes the workflow of a POD job being submitted through an e-print
procurement application. The example provides a basic understanding of the required
processes for the completion of a print job. It points out the shortage of a streamlined
workflow at the printer and missing integration of the e-print procurement application
into the print shop's workflow. The presentation of the workflow at the print shop is
based on a visit to a digital printer. Certain processes may differ from this example, depending on the print job, printing method and assisting software systems.
3.1.1 Print Broker
The print broker collects the assets, such as the company’s logo, images and fonts for
the collateral that needs to be printed. He designs the print object and creates a first
10
11
Workflow Management Coalition, Terminology & Glossary, 1999, P. 8.
CIP4, JDF Specification, 2002, P. vi.
© 2003 by Catherine Dammann.
3 The Print Production Workflow
11
file. He solicits quotations and proofs from appropriate printers. Once the print buyer
has approved the proofs, the file and price lists are uploaded to the software’s database.
The print buyer can now log in to the application. The software allows the entry or
change of personal data (such as name, phone numbers etc.) and specification of the
job (such as paper quality, finishing instructions or a different delivery address). Once
the print buyer has chosen one of the associated printers, he submits the order. The
software creates a print-ready file of the actual order and attaches it to an electronic
mail (e-mail). The job specifications are inserted in plain text. Figure 7 illustrates the
workflow at the print broker.
Figure 7: Workflow of a Print on Demand Job at the Print Broker
Source: Author’s Figure
3.1.2 Print Shop
The order management receives the print order via e-mail and creates the job ticket.
The job ticket is a container for all print job related information that moves along the
workflow until job completion. It specifies the print instructions and the location of content file(s). Here, it is created by electronically copying relevant data from the order email to a spreadsheet template file. The provided data includes:
© 2003 by Catherine Dammann.
3 The Print Production Workflow
•
•
•
•
•
•
•
12
Order date
Print buyer's name and address
Unique order number of the e-print procurement application
Order type (e.g. business cards or brochures)
Order quantity
Paper type and weight
Delivery address
Additional information to the job ticket consists of:
• The job ticket number - One job ticket represents all orders from one print buyer
in one invoicing period (e.g. one month)
• The delivery method - It is distinguished between local delivery provided by an
own delivery team and national delivery, provided by shipping companies (such
as FedEx).
The content file attached to the e-mail is opened and checked. The file is then converted into PostScript, the processing format for the press area. The Raster Image
Processor (RIP) of the respective digital press receives the file converting it to their
proprietary format. The printed job ticket is handed over to the press operator. The
press operator calculates the required amount of print sheets based on the provided
order quantity and imposition schema in the file. The number is manually entered into
the Machine Control Console (MCC) of the digital press.
Once the job has been printed, the printed sheets and job ticket are carried over to the
postpress area for cutting and wrapping according to the job ticket specifications. From
there, the final packets and the job ticket are handed back to account management.
The delivery form is filled out (handwriting) with delivery details and handed over to the
delivery team. Once the prints are delivered, the delivery form is brought back and filed
together with the job ticket of the completed job.
After the production of several jobs, the spreadsheet file containing all completed job
tickets is sent via e-mail to the invoice/accounting department. There, the spreadsheet
files with the job tickets and the current price list are joined together creating invoice
data.
At the end of the invoicing period, the spreadsheets are printed out. The invoicing details are manually re-entered into order management software that creates the invoices. The spreadsheets with the more detailed job specifications are attached to the
invoices and sent to the print buyer. A batch file of the invoicing data in Comma Separated Value (CSV) format is digitally exchanged with the accounting software in the corresponding department where the data is further processed.
© 2003 by Catherine Dammann.
3 The Print Production Workflow
13
The above-described workflow lacks data exchange automation between the involved
parties and systems. Quoting is a manual process between the print broker and print
shop. The e-print procurement software provides the job specification, which is manually copied into the corresponding columns of the spreadsheet file. The spreadsheet is
printed out to create a paper-based job ticket that is physically passed along the remainder of the workflow. Any import/export functionality of existing software systems is
barely employed. The print shop has order management software that provides functionalities for estimating, job ticketing and invoicing. The required information for creating a job ticket, however, is too voluminous for standardised orders from the e-print
procurement application. A spreadsheet template file and its print out therefore replace
the software's job ticket. When invoicing, the order management application’s importing
functionality is not used because the spreadsheet's format does not match the import
schema.
Until recently, the data exchange interface between order management software and
accounting software had not existed. After invoicing, data had to be printed out and reentered into the accounting application. The current interface for exporting data in CSV
format has been programmed and implemented according to the print shop's specific
requirements. The order management software provides the business management
with limited sales statistic data. As they demand the data to be more detailed for further
business analysis, it is exported in CSV to a spreadsheet application and further processing. Figure 8 illustrates the entire workflow of a POD-job.
© 2003 by Catherine Dammann.
3 The Print Production Workflow
14
Figure 8: Entire Workflow of a Print on Demand Job
Source: Author’s Figure
3.2 The Digital Workflow
3.2.1 Data Exchange
For job processing, each division in a given print shop requires specific information
about the job. Data that is transferred along the workflow generally consists of:
• Administrative data such as customer information, job number and deadlines.
• Product data such as paper quality, quantity and binding technique.
• Production process data such as imposition layout, ink brand and machine settings.
• Content data, including page images, formatting and colour information, which is
used to create a print production file
This data forms the job ticket.
General systems at the print shop are Management Information System (MIS) on the
business level and Technical Workflow Systems (TWS) in production. MIS is responsible for job planning and controlling. It oversees the entire workflow and provides management data for resource scheduling, process control and financial activities. It generally consists of the following modules:
• Inquiry and Order Management (IOM). An IOM module manages all job handling
processes such as inquiries, quotations, orders and invoices.
© 2003 by Catherine Dammann.
3 The Print Production Workflow
15
• Production Planning and Controlling System (PPS). A PPS module assists in production scheduling and process control. It tracks process results, controls machine workload and transfers job status notifications.
• Accounting and Inventory Management. These modules may exist as dedicated
systems.
TWS controls processes in production. It controls the automated output of a content file
to the press area. Depending on the print shop and job, tasks of TWS may include:
•
•
•
•
•
Pre-flight
Trapping
Proof Output
Page Imposition
Colour management/colour space conversion
An Operating Data Acquisition (ODA) system interfaces business management and
production in recording and submitting process results and consumption from production to the PPS module.
Large volumes of data exchange occur in the prepress phase of production. TWS
therefore focuses on this area as various devices and systems need to be controlled.
Between production and MIS, data is continuously exchanged. Production data is
handed over via ODA to MIS while MIS processes the given information and in turn,
transfers further planning data back to production.
External partners assist the print shop in job completion:
• Paper and ink suppliers supply consumables.
• Prepress and finishing suppliers deliver services.
• Print brokers supply jobs.
“While the new ‘print-dot-com’ sales models hold a lot of promise, it is clear that they
will reach their full potential only when they are seamlessly connected with the manufacturing side of the print job. … Industry will remain slow to adopt the B2B [Businessto-Business] Internet solutions until the newly proposed business models can offer the
productivity boosts that can be fulfilled only by removing crucial bottlenecks in the total
order-to-delivery cycle.”12
The efficient production of a print job requires a digital workflow through Electronic
Data Interchange (EDI) between processes and systems. “Electronic Data Interchange
specifies techniques enabling exchange of structured data between computers across
12
ScenicSoft, UpFront, 2001, P. 5.
© 2003 by Catherine Dammann.
3 The Print Production Workflow
16
a network.”13 The EDI of job specifications between the print broker's e-print procurement software and the print shop ensures workflow inter-operability. Both benefit from
the reduction of errors and misunderstandings related to job parameters. Time and cost
intensive requests are eliminated and re-keying of order information avoided. This results in an optimised print value added chain.
Figure 9: Print Shop Business Systems Integration with Web Infrastructure
Source (based on): WhatTheyThink.com, Spending, 2002
Figure 9 shows the current and planned integration of web infrastructure into print
shops’ business systems. The incorporation of production and estimating systems is
where most print shops will focus on in 2003.
For effective EDI to take place, all involved systems must understand a common data
structure.
3.2.2 Current State
The need for an improved EDI to build a digital workflow in the commercial printing industry has been recognized, but to this point only partly implemented. Today, data exchange between machinery and systems in production is restricted due to proprietary
and limited open formats. In the current state, TWS vendors use their own data formats
for the information exchange between software modules and to cooperating vendor’s
machinery. The connected systems remain closed since interfaces to other vendor's
13
Workflow Management Coalition, Workflow and Internet, 1998, P. 17.
© 2003 by Catherine Dammann.
3 The Print Production Workflow
17
machinery and to MIS are missing. Large printers have proprietary solutions that were
tailored to their individual needs, for establishing an automated workflow between all
involved systems. These solutions link different machines and even interface to a MIS,
but high expenditures and limited scalability restrict this method to a few companies.
“The industry has struggled to improve efficiencies by adding various digital pieces to
the process, but in most cases, the impact has been limited, with a focus more on
manufacturing than complete process reengineering.”14 “CAP Ventures, a leading analyst of the print industry, estimates that nearly one-third of the dollars spent on print are
wasted due to inefficiencies in the workflow process.”15
Adobe Systems Incorporated has developed the Portable Job Ticket Format (PJTF),
which is an open format that is used for job data exchange in prepress. The Ifra (INCAFIEJ Research Association [INCA stands for International Newspaper Colour Association, FIEJ stands for Fédération Internationale des Editeurs de Journaux]) developed
the Ifra Message Format (IMF) for status data exchange in the newspaper production
industry. The International Cooperation for Integration of Prepress, Press and Postpress (CIP3) started in 1993 to work on an open format for interoperability between
heterogeneous print production systems. The multi-vendor collaboration issued the
Print Production Format (PPF) in 1995. PPF is a container for press and postpress machine set-up data.
As PJTF and PPF only partly connect production areas, the systems involved in a print
job are still incapable of working as a coherent unit. “Another way to increase
productivity, besides increasing efficiency within individual departments, is to establish
or improve the integration and connectivity between different departments.”16 The
recognition of this missing link between production and business management
prompted CIP3 to overhaul its efforts for providing a standardised comprehensive data
exchange format.
In 2000, CIP3 changed its name to the International Cooperation for Integration of
Processes in Prepress, Press and Postpress (CIP4) and proposed JDF. JDF is an
open file format for the commercial printing industry. It provides comprehensive job related parameters for all processes.
14
Cap Ventures, Print e-Procurement, 2000, P. 2.
Printcafe, Print E-procurement, 2002, P.2.
16
ScenicSoft, UpFront, 2001, P. 12.
15
© 2003 by Catherine Dammann.
3 The Print Production Workflow
18
3.2.3 Computer Integrated Printing
Establishing a digital workflow through an open format adopts the idea of Computer Integrated Manufacturing (CIM) for the commercial printing industry, i.e. Computer Integrated Printing (CIP). “The major concepts of CIM are:
• The installation of a network of all machines and devices in the workflow in order
to enable them to exchange data among each other;
• A digital file which contains all information necessary to produce a particular
product and which can be interpreted by all machines and devices in the network
(“digital job ticket”).”17
Business and production management benefit from CIP in process transparency leading to an improved operation overview. The improved information flow results in shorter
production cycles, empowering the print shop to be more competitive. Redundant data
is eliminated and data accuracy is improved. Repeated orders can be effectively processed, as all job parameters are available in one file. “Possible benefits of a networked
system are:
•
•
•
•
Productivity increase in production (3-10%)
Reduction of run-through time (10-30%)
Stock optimisation in material management (10-30%)
Profit increase through cost savings (5-15%).”18
Using the Internet to connect the print broker and print shop via JDF, results in extending the print shop’s network of e-print procurement. “Printing is no longer just about
printing. It is becoming a business in which production processes and supply-chain relationships become integrated using databases and networked information flows.”19
Figure 10 shows the integration of the Internet into the print shop’s network.
17
INI-GraphicsNet, Printing, 2001, P. 5.
Thimm, Praxisbeispiel Workflow, 2000, P. 11, Original source: HD Datensysteme (without further source indication), Original text: 'Mögliche Ergebnisse eines integrierten Systems: Poduktivitätssteigerung in der Produktion (3-10%), Reduzierung der Durchlaufzeiten (10-30%), Optimieren der Bestände in der MAWI (10-30%), Gewinnsteigerung durch Kosteneinsparung
(5-15%)'.
19
Cahners Research, E-Commerce Exchange, 2000, P.7.
© 2003 by Catherine Dammann.
18
3 The Print Production Workflow
19
Figure 10: Extending the Print Management System for Internet Business
Source (based on): Printcafe Europe, Print Management Systems, 2000, P. 12
© 2003 by Catherine Dammann.
20
4 Data Exchange Formats
This chapter describes data formats for EDI in the commercial printing industry. An
overview of content data exchange formats is given before formats for the exchange of
business data are described.
4.1 Content Data Exchange
Content data, e.g. text, graphics, images, fonts and colour, used to be exchanged via
an analogue medium such as film. In CIP, content data is contained in a digital file that
is exchanged between external DTP partners and print shops and within print production. This file is encoded in a Page Description Language (PDL). A PDL is “a language
for describing the graphical appearance of pages with respect to an imaging model.”20
There are proprietary PDLs (such as of DTP applications or Hewlett-Packard Corporation’s PCL (Printer Control Language)) and open PDLs. These can be divided into vector-based (such as Portable Document Format (PDF), PostScript, Encapsulated PostScript (EPS) or Scalable Vector Graphics (SVG)) and raster-based PDLs (such as
Tagged Image Format (TIFF), Graphics Interchange Format (GIF) or Joint Photographic Experts Group (JPEG)). Raster-based PDLs compose a page of pixels (bitmaps) whereas vector-based PDLs describe an image by using mathematical relationships between points. Raster-based PDLs are mainly used for photographs and other
shaded images. When scaling a raster image up for print, the image edges become
jagged. Therefore, vector-based PDLs are used whenever possible in commercial
printing.
All print data files are converted into the device-independent PostScript during print
production. PostScript acts as an interface between the proprietary PDL of a DTP application and the proprietary device control language of an output device (see figure
11). The point of conversion depends on the workflow being employed. Commonly
used workflows are PostScript and PDF Workflows. Among the vector-based formats,
PDF has been established as the de-facto standard for platform and application independent page transfer in the commercial print industry.
20
Adobe, PDF Reference, 2001, P.10.
© 2003 by Catherine Dammann.
4 Data Exchange Formats
21
Figure 11: PostScript as a Universal Format in Print Production
Source: Author’s Figure
4.1.1 PostScript
PostScript is a programming language, containing printer-control commands, and a
page description language containing additional print production commands. Introduced in 1985 by Adobe Systems Incorporated, PostScript targeted the output of complex graphic pages from low power personal computers (PCs) onto print devices.
PostScript is licensed to print equipment manufacturers.
Figure 12 shows three PostScript commands.
Figure 12: Example of PostScript Commands
Source: Author’s Figure
© 2003 by Catherine Dammann.
4 Data Exchange Formats
22
The elements of a PostScript file are distinguished in text, graphics and image objects.
“As a general-purpose programming language, PostScript contains procedures, variables, and control constructs that must be interpreted to render its page description.”21
Before a PDL file is output, it is processed by the output device's RIP that contains a
PostScript interpreter. The PostScript Interpreter interprets the sequential PostScript
file and creates an internal page display (display list). “It is in the display list that the
PostScript interpreter stores all the calculated objects for a page in a uniform format.”22
When rendering, the file is first converted into pixels (byte map) in the resolution of the
target device and finally into a bitmap (single dots) that are imaged onto media. A
PostScript Level 3 interpreter allows a RIP to process or interpret PDF files directly.
As a device-independent language, a PostScript file can be printed on professional
printing equipment as well as on office and home printers. PostScript ensures the consistency of the page appearance and full utilisation of the output device capabilities.
One main disadvantage of PostScript as a PDL for data exchange is the file size. All
prepress applications in a PostScript workflow read and interpret the file, which is
memory and time intensive. In addition, some PostScript files contain device-specific
commands causing error messages while being interpreted by a third-party PostScript
interpreter. The complexity and sequential structure of a PostScript file makes single
page extract for imposition and changes difficult.
4.1.2 Portable Document Format
PDF was introduced in 1993 by Adobe Systems Incorporated. “It was intended as a
means of exchanging documents effortlessly between various computer systems without the recipient having to install all the software and fonts used to generate the original document.”23 Its current specification 1.4 was introduced in 2000.
From the initial use as a universal format for office environments, the commercial printing industry has adopted PDF as a suitable format for the print production process.
Several TWS are PDF-based. “A PDF workflow can be defined as any process that
creates or accepts PDF files, prepares them for printing, or outputs them to film, plate,
or press.”24 Figure 13 shows a PDF-based workflow.
21
Adobe, PDF for Prepress Workflow, 1997, P. 1.
Jaeggi, Basics, 1999, P. 10.
23
Ibid., P. 4.
24
Agfa-Gevaert, PDF Workflows, 1998, P. 7.
22
© 2003 by Catherine Dammann.
4 Data Exchange Formats
23
Adobe System Incorporated’s offering for creating, viewing and editing PDF files is the
Acrobat software package. The Reader for PDF file viewing is available free of charge.
PDF files can be created with the Distiller. Software development enterprises are able
to create PDF files within their application using PDF library from Adobe Systems Incorporated (subject to licensing) or open PDF libraries such as PDFlib.
Figure 13: The PDF-Workflow
Source (based on): Jaeggi, Management, 1999, P. 8
PDF is an object-based language containing objects such as lines, arcs, and circles for
page description. A PDF file resembles a database of accessible objects. The crossreference table contains the file locations of each object. A PDF file can consist of a
single page, multiple pages (for instance all pages of a brochure) or a signature (imposed pages). These documents contain the required page description data for highend printing. Graphics are stored as raster or vector images. PDF has the ability to
embed font matrix data into the file, thus enabling a system to view it without having the
used fonts installed. The PDF creator can include print specific instructions such as
cutting marks, bleed data, colour schema, crop marks or register marks. The elements
in a PDF document can be compressed, making the PDF file significantly smaller than
the initial graphic file or the PostScript file. “Optimum compression can cut data vol-
© 2003 by Catherine Dammann.
4 Data Exchange Formats
24
umes up to 90%.”25 Furthermore, PDF allows down-sampling of image resolutions to
achieve a smaller file.
In contrast to other PDLs, PDF combines several advantages. Print shops used to face
issues such as file incompatibilities, missing fonts and different document appearance
when receiving files from DTP professionals. This is due to the number of layout applications for different operating systems, resulting in inaccurate and therefore unreliable
files. A PDF file is platform-independent regarding the generating operating system and
layout software. Conversion and compatibility issues are therefore eliminated and interoperability between multi-vendor equipment and software is ensured. The objectbased data storage allows easy replacement of pages or editing single objects where
desired. This gives flexibility for last-stage changes before 'RIPping'. Single pages can
be extracted from a PDF file, as every page is self-contained, i.e. has sufficient data to
stand by itself. In contrast to pages in a PostScript file, this facilitates the page division
in the imposition process. Random access allows parallel page rendering. A PostScript
file can only be sequentially processed, requiring more preparation time for output. The
size of a PDF file enables an efficient file transfer via e-mail between print shop and
DTP partner and across the print shop's network. Print buyers can benefit from remote
proofing when receiving a PDF proof via e-mail that is printable on their own printer.
Once generated, a PDF file can be used by the print shop or the customer as a universal medium for digital publishing on a Compact Disc-Read Only Memory (CD-ROM) or
on the Internet.
The PDF/X format is a subset of PDF specifically dedicated to the requirements of the
commercial printing industry. PDF/X provides improved colour management.
4.2 Business Data Exchange
Business data comprises of administrative, product and production data. After an overview of proprietary formats, the main part introduces JDF as a means for electronic
business data exchange. Its predecessors PJTF, PPF and IMF are described as the
basis upon which JDF has been developed. After an overview on XML, the model and
fundamental components of JDF are described. A market analysis points out the current adoption and potential of JDF as standard format for business data exchange in
the commercial printing industry.
25
Jaeggi, Management, 1999, P. 14.
© 2003 by Catherine Dammann.
4 Data Exchange Formats
25
4.2.1 Proprietary Formats
The Content File Exchange (CFX) format was introduced by CreoScitex (now Creo Incorporated) in 2000. CFX is a container structure for the job exchange in Creo’s PDFbased TWS Prinergy. A CFX job file contains a Prinergy refined PDF file, optional
JPEG Thumbnails, a populated PJTF file (containing layout and runlist data) and JDF
data for page colour information. As JDF becomes more prevalent in the industry, Creo
expects to move the entire job data to JDF, basing the whole container on PDF and
JDF.
The EProduction ECommerce Exchange format (PCX) was introduced in 2000 by
Printcafe Software Incorporated. PCX interfaces external systems with Printcafe’s
software products through one interface. These systems may be from certified PCXpartners comprising vendors of B2B, e-procurement, supply chain, content management or production systems. The PCX initiative has been rolled into Printcafe’s adoption of JDF.
The Electronic Ticket Format (e-t-f) was initially introduced in 2000 as a format for the
digital transfer of advertisement information. It also provided templates for simple
printed jobs. E-t-f provided a container for limited business data exchange. It interfaced
the customer to order management systems at the print shop or newspaper, respectively. It was developed by a joint venture between Callas Software GmbH (a prepress
software company), Hermstedt AG (a manufacturer for ISDN communication products)
and Zeitungsmarketing GmbH (ZMG, a central marketing body for all German newspapers). The development of e-t-f was stopped because the publishing industry could not
agree on the specific content of the format.
4.2.2 Job Definition Format
JDF is a file format that defines a comprehensive electronic job ticket embracing all
processes in a print workflow. “It provides the means to describe print jobs in terms of
the products eventually to be created, as well as in terms of the processes needed to
create those products.”26
A JDF print workflow is controlled on a horizontal level with a JDF job ticket. Job and
process description move from system to system within production. JDF's messaging
mechanism Job Messaging Format (JMF) connects the vertical level. Status and economic data moves between MIS and production (see figure 14).
26
CIP4, JDF Specification, 2002, P. 1.
© 2003 by Catherine Dammann.
4 Data Exchange Formats
26
JDF’s capability of capturing the complexity of print production results in these core
features:
•
•
•
•
It accompanies a print job from the beginning to the end covering all aspects.
It does not require pre specified workflows.
It can be used by print shops of every size.
It is capable of defining all varieties of printing products (such as brochures, letterheads or books).
• It can be used for all printing methods (such as Offset, Digital, Flexographic or
Web).
Figure 14: Scope of JDF
Source (based on): Heidelberger Druckmaschinen AG, JDF Technical Overview, 2000, P. 3
In February 1999, Heidelberger Druckmaschinen AG, MAN Roland Druckmaschinen
AG, Adobe Systems Incorporated and Agfa-Gevaert N.V., all in graphical arts and print
industries, started to work on a comprehensive job ticket format. They were aiming at
creating an EDI between all parties and systems involved in a print job. “The idea was
to develop a set of open, extensible, XML-based job ticket standards, as well as a
mechanism that provides new business opportunities for all individuals and companies
involved in the process of creating, managing and producing published documents in
the new economy.”27 The first draft of the JDF specification was introduced in 2000. In
August of the same year, the rights were transferred to the newly founded crossindustry consortium CIP4 for further development and maintenance. CIP4 has 144
members now (17. February. 2003). The current release of the JDF specification is 1.1
Revision A from September 2002.
27
CIP4, Job Definition Format, 2000, P. 1.
© 2003 by Catherine Dammann.
4 Data Exchange Formats
27
Other bodies are currently involved in driving the JDF development. The European
Print Management Association (Euprima) is an alliance of MIS vendors that are committed to improve the development of common JDF interfaces between production and
business management. The association was established in 2000. The PrintTalk consortium consists of print industry experts from e-commerce companies, MIS vendors,
print shops and print equipment manufacturers. PrintTalk provides an XML-based format for the communication of print related business information in an e-commerce environment. The consortium was established in June 2000.
4.2.2.1
Predecessors
JDF has been developed upon the data exchange formats PJTF, PPF and IMF. PPF
elements and PJTF objects were mapped to JDF resources. Sheet definitions, Colour
objects, Trapping and Pre-flight were taken from PJTF whereas PPF provided press
and postpress instructions. IMF’s message functionalities were integrated in JMF.
1
Portable Job Ticket Format
PJTF is an open prepress job ticket format based on PDF objects. Its current specification version is 1.1. A PJTF job ticket contains prepress processing instructions and
provides prepress generated set-up data for printing devices. Information that may be
contained in a PJTF file includes28:
•
•
•
•
•
•
•
•
Page processing instructions (such as imposition layout)
Output parameters (such as resolution)
Media (such as paper size and weight)
Finishing instructions
PPF data (such as ink setting parameters)
Delivery information
Scheduling information (such as deadlines)
Administrative data (such as customer number)
The PJTF job ticket file consists of job ticket objects that conform to the PDF objects
specification. All hierarchically organized objects descend from the root object JobTicket. “Job ticket objects comprise sets of key/value pairs. Each key/value pair
represents one attribute of the PJTF object.”29 A PJTF job ticket can exist as a stand-
28
29
According to: Jaeggi, Basics, 1999, P. 11.
Adobe, Portable Job Ticket Format, 1999, P. 7.
© 2003 by Catherine Dammann.
4 Data Exchange Formats
28
alone .jtf-file in job ticket format, which is then assigned to the PDF content file. Otherwise, it resides independently in the PDF file itself.
PJTF and PDF are the integral parts of the prepress architecture Extreme from Adobe
Systems Incorporated. Extreme is a job management framework, licensed to Original
Equipment Manufacturers (OEM), who customise their TWS on it. Extreme's software
modules consist of the Job Ticket Manager that creates the PJTF job ticket. Job Ticket
Processors (JTPs) consume job tickets and perform the given instructions. JTPs can
be found within every printing device and software component that is required to perform job processing. OEMs can add and modify JTPs adding unique value to their
software product. A Coordinator controls the sequence of required JTPs in a particular
workflow. “A Job Ticket collects information about the state of the document and what
needs to happen to it. This information is passed to the Coordinator, which determines
which Job Ticket Processors are required. The JTPs then effect the required processing and pass the document to the next part of the sequence.”30
PJTF provides a means for precise process specification in prepress. Although it also
provides data for processes beyond prepress operations, such as customer or delivery
information, this information only covers limited aspects of a print job. PJTF is only capable of uni-directionally transferring data. The customisation of applications within the
Extreme architecture results in custom elements in PJTF, which are specific to a software product. This may cause interoperability problems even though PJTF is used for
data exchange.
2
Print Production Format
PPF is a PostScript-based file format containing data for machine presetting in press
and postpress. The information that is gathered at job entry into the MIS and during
prepress operations is shown in figure 15. CIP3 was assisted by the Fraunhofer Institute for Computer Graphics (Fraunhofer IGD) in introducing the first version of PPF in
1995. The specification is currently in its version 3.0 from 1998.
30
Adobe, PostScript Extreme, 1998, P. 2.
© 2003 by Catherine Dammann.
4 Data Exchange Formats
29
Figure 15: The PPF Workflow
Source (based on): CIP3, CIP3 Print Production Format, 1997, P. 2
A PPF file can be a stand-alone .ppf file or embedded in a PostScript file. It consists of
the following elements (see figure 16):
• The PPF directory provides the sheet names, definition lengths and position.
• The Product Definition (optional) specifies the required components.
• The Sheet Definition (s) consists of attributes, structures and content types.
Figure 16: Building Blocks of a PPF File
Source (based on): CIP3, Specification of the CIP3 Print Production Format, 1998, P. 6
© 2003 by Catherine Dammann.
4 Data Exchange Formats
30
The following extract of a PPF file shows an example of encoded cutting data in PPF31:
CIP3BeginCutData
CIP3BeginCutBlock
/CIP3BlockTrf [1 0 0 1 44 mm 45.9 mm] def
/CIP3BlockSize [ 420 mm 594 mm] def
/CIP3BlockElementSize [210 mm 297 mm] def
/CIP3BlockSubdivision [2 2] def
/CIP3BlockType /CutBlock def
/CIP3BlockElementType /CutElement def
/CIP3BlockName (Front Sides) def
CIP3EndCutBlock
CIP3EndCutData
While a PPF file is parsed by a PostScript Interpreter, process control data for machine
presetting is extracted. Administration data for documentation purposes can be extracted. Printed on a PostScript-enabled printer, job completeness can be checked.
Private data fields enable the storage of job data for repeated runs, so that the PPF file
can be used as a data archive. This enables an economical turnaround of repeat jobs.
In employing data that is available at job entry on the business level and created during
prepress operations, PPF links press and postpress to previous processes. “It is important that these data [all information relevant for setting up, running and controlling the
machines] are so abstract that they can be used for any set of press and not only for a
particular set of machines of a particular manufacturer.”32 Thus, data re-entry is
avoided and accuracy of measures such as colour and cutting marks is ensured. This
leads to shorter production cycles through faster make-ready.
PPF acts as a container for uni-directional data flow from prepress to press and postpress equipment. The format cannot be used for data feedback from equipment to the
MIS, such as job execution information or error messages. PPF only contains technical
data and cannot capture comprehensive administrative or scheduling data.
3
Ifra Message Format
IMF specifies status data exchange in newspaper production. It was developed by the
publishing industry association Ifra. IMF is part of the IfraTrack production system
31
32
Example from: CIP3, CIP3 Print Production Format (PPF), 1997, P.2.
INI-GraphicsNet, Printing, 2001, P. 7.
© 2003 by Catherine Dammann.
4 Data Exchange Formats
31
whose current specification 3.0 was developed in collaboration with CIP4 in order to
achieve compatibility with JDF. Since version 3.0, IMF has been based on XML.
4.2.2.2
The Extensible Markup Language
JDF is encoded in XML. A markup language as a descriptive language “is a set of
symbols that can be placed in the text of a document to demarcate and label the parts
of that document.”33. These symbols are called elements. XML lets developers define
custom elements for their specific field of application. As such, XML is a meta-language
that is used to define new markup languages.
XML was introduced in 1997 as a simplified subset of the more complex Standard
Generalized Markup Language (SGML). Its current specification 1.0 was published by
the World Wide Web Consortium (W3C) in February 1998.
In contrary to the commonly known Hypertext Markup Language (HTML) whose elements are used for formatted data display on the Internet, XML elements define the
structure of the information. For outputting an XML document (called an XML instance),
separately stored style sheets need to be applied. Style sheets for different views or
print can be created in Cascading Style Sheets (CSS) or the Extensible Stylesheet
Language (XSL).
Every XML instance must be well-formed. A well-formed XML document follows all of
the notational and structural rules for XML that are defined in the XML specification.
When creating a new XML-based markup language (called a document type), the specific rules for this language are defined in its Document Type Definition (DTD) or the
newer XML-schema. “While a well-formed document is well-formed because it follows
rules defined by the XML spec, a valid document is valid because it matches its document type definition (DTD). The DTD is the grammar for a markup language, defined
by the designer of the markup language. [...] The DTD specifies what elements may exist, what attributes the elements may have, what elements may or must be found inside
other elements, and in what order.”34
For document validation, using the emerging XML-schema instead of a DTD extends
XML's capabilities. An XML-schema primarily allows the definition of standard and own
data types for elements. This facilitates an accurate XML data exchange with a database. The commercial printing industry needs the definition of own data types, since
33
34
Ray, Learning XML, 2001, P. 2.
Johnson, XML for the absolute beginner, No publishing date, P. 4.
© 2003 by Catherine Dammann.
4 Data Exchange Formats
32
industry standards require having data types for specific data (such as for page sizes
or colour codes). An XML schema also provides the use of namespaces. “An XML
namespace is a collection of names, identified by a URI [Uniform Resource Identifier]
reference […] which are used in XML documents as element types and attribute
names.”35 The concept of namespaces enables one to refer to multiple document types
in one XML instance. Using namespaces provides opportunities for the format’s extension, as software vendors are able to add private elements and attributes to existent
JDF elements. Flexibility for the commercial printing industry’s development is therefore ensured by validating a JDF file against XML schema.
The validation of an XML instance is executed by an XML processor (a parser) that reports errors if elements do not match the schema or DTD. “The parser turns a stream
of characters from files into meaningful chunks of information called tokens. The tokens
are either interpreted as events to drive a program, or are built into a temporary structure in a memory (a tree representation) that a program can act on.”36 Figure 17 illustrates the parsing of an XML instance.
Figure 17: Three Steps of Parsing an XML Document
Source (based on): Ray, Learning XML, 2001, P. 9
35
36
World Wide Web Consortium, Namespaces in XML, 1999.
Ray, Learning XML, Sebastopol 2001, P. 9.
© 2003 by Catherine Dammann.
4 Data Exchange Formats
33
Applications access the XML information through an Application Programming Interface (API). Two common XML Application Programming Interfaces are the event-based
Simple API for XML (SAX) and the tree-based Document Object Model (DOM). The
W3C recommended DOM is a platform and language neutral interface that defines
methods for the creation and manipulation of objects. “The DOM opens the door to using XML as the lingua franca37 of data interchange on the Internet, and even within
applications.”38.
The language independency of the XML Application Programming Interfaces ensures
application independent access to XML. XML is therefore regarded as the core format
for data exchange as figure 18 shows.
Figure 18: The Importance of XML
Source: Cap Ventures, Assembling the Content Foundation, 2001, P. 19, Original Source: CAP
Ventures, Understanding the Early Markets for XML, 1999
37
Definition „Lingua Franca” by Centre for Applied Language and Literacy Research, quoting
the United Nations Educational, Scientific and Cultural Organization (UNESCO) in: Pidgin’s and
Creole Languages, no year, http://www.ecu.edu.au/ses/research/CALLR/swociowww/
3_1_1.htm (10. Nov. 2002): „A language which is used habitually by people whose mother
tongues are different in order to facilitate communication between them.”
38
Johnson, XML for the absolute beginner, No publishing date, P. 8.
© 2003 by Catherine Dammann.
4 Data Exchange Formats
34
An XML instance begins with a document prologue. The main component is the XML
declaration that usually also provides the version of XML used for creating the XML instance. “The XML declaration is an announcement to the XML processor that this
document is marked up in XML.”39 A valid XML declaration can be encoded like the
following:
<?xml version=”1.0”?>
Further content of the document prologue provides encoding information, XML processing instructions and a document type declaration. If another namespace than the
standard XML namespace is defined as default, this XML attribute needs to be inserted
in the corresponding node:
xmlns:xsi=”Uniform Resource Locator (URL) of my unique namespace”
The basic component of an XML instance is an element. The content the element describes is embraced by a start and corresponding end tag. The element's name is enclosed by angle brackets. The top-level element of an XML instance is called the root
element. All following elements nest inside the root element and in turn nest within
themselves, structuring the XML instance accordingly (see figure 19).
39
Ray, Learning XML, 2001, P. 33.
© 2003 by Catherine Dammann.
4 Data Exchange Formats
35
Figure 19: XML Elements and Corresponding Tree Structure
Source (based on): Ray, Learning XML, 2001, P. 30
An element having another nested element is called a parent element (or ancestor).
The nesting element is called child element (or descendant), which in turn may be the
parent element for further nested child elements.
An element may include a list of attributes, defining the element's properties. “Attributes
are mainly used for modifying an element's behaviour rather than holding data.”40 Attributes occur inside the start-tag after the element's name and consist of a name-value
pair. Each child element inherits the attributes of its parent element, which in turn may
inherit attributes from its own parent element.
XML provides methods to externally and internally link to resources. The basic external
linkage (such as to another XML instance, a graphical file or a software application) is
provided by using a URI or public identifiers. JDF references the PDL file (s) via a URI,
ensuring the format's independency from the respective encoding PDL.
40
Ray, Learning XML, 2001, P. 31.
© 2003 by Catherine Dammann.
4 Data Exchange Formats
36
Internal links point to specific elements within one XML instance by uniquely labelling
these elements with the attribute type ID. The target element can be referenced by the
referring element in employing its attribute type IDREF.
4.2.2.3
1
Specification
Model
A JDF file defines one print job. The file consists of XML elements (called nodes) each
representing the final product, its components and the required processes that need to
be executed. “All of the nodes taken together describe the desired printed product and
the workflow of its production.”41 According to the nesting of elements, these nodes can
be hierarchically structured as a tree as shown in figure 20.
Figure 20: JDF Tree Structure
Source: CIP4, JDF Specification, 2002, P. 14
The top node (root element) describes the intent of the print job, i.e. the desired product. Its direct sub-nodes define the product’s components. These sub-nodes are then
further divided into subsequent nodes describing “increasingly process-oriented aspects of the job, until the nodes at the bottom of the pyramid [the tree] each describe a
single, simple process.”42 As a result, the top of the tree represents abstract job information while detailed process information is found in the tree’s leaves.
41
42
CIP4, Job Definition Format, 2000, P. 3.
CIP4, JDF Specification, 2002, P. 10.
© 2003 by Catherine Dammann.
4 Data Exchange Formats
37
The JDF file structure (the amount of levels and nodes on each level) is dependent on
the individual job. It is determined by the component structure and job requirements.
Certain print jobs in JDF may consist of several single process nodes right below the
top product node whereas others may have a number of process groups nested in
product component nodes.
2
Components
The root element of a JDF file is a JDF element containing JDF child nodes, attributes
and elements. All JDF nodes and their elements are XML elements. The JDF specification, however, refers to a JDF element with the term 'node' whereas their structured
subparts are called elements. In the course of this document, this use of terms is continued. Figure 21 shows the structure of a JDF node with all its elements:
Figure 21: The JDF Node and its Child elements
Source: CIP4, XML Schema for JDF, 2002
Each element is described in the following table.
Name
Description
AncestorPool
JDF allows nodes of one job to be independently processed by sub
contractors (for instance for special finishing at a finishing service).
This is achieved by using the spawning and merging mechanism.
This element occurs only if the current JDF node has been spawned.
It contains a list of all ancestor elements prior to spawning for an accurate merge backwards.
© 2003 by Catherine Dammann.
4 Data Exchange Formats
AuditPool
Comment
CustomerInfo
NodeInfo
ResourcePool
ResourceLinkPool
StatusPool
JDF
38
A list of audit elements. These elements record events (such as a
node's creation or modification) and process results (such as resource consumption or process times) during processing.
The reporting information supports the MIS in comparing planned
and actual data for quality control, re-calculations and invoicing.
A text element containing human-readable text. This element belongs
to a set of generic structures provided for human-readable comments
and descriptions for each JDF element (see section 'Generic Contents' in 5.2. Product Specification).
A container element for customer data (such as a customer's unique
ID, company, a contact person's details). Usually defined in the root
node of a job.
An element for planning a job's scheduling and messaging routing. It
comprises information such as a job's planned start and end date
and time, the URL of the executing device or the estimated process
duration.
A list of Resource elements. See section 5.2.1.2 Resources.
A list of ResourceLink elements. See section 5.2.1.3 ResourceLinks.
JDF allows processing partitioned resources. List of the node's partition.
JDF child nodes.
Table 1: JDF Child Elements
All JDF nodes are categorised as product nodes, process group nodes, combined
nodes and process nodes by specifying the attribute type. Each JDF node is uniquely
identified by the attribute ID, used for internal linking by subsequent nodes.
JDF nodes consume resources during execution and create resources after being
processed. All these physical, electronic and logical items are divided into input and
output resources. “Inputs in a node describing the process for creating the cover of a
brochure, for example, might include the inks, the press sheets, the plates, and a set of
parameters that indicate how many sheets should be produced. The output of the
process node using these particular inputs will be a set of printed press sheets.”43 JDF
nodes and their resources interact following a producer/consumer model that is illustrated in figure 22:
Figure 22: JDF Producer/Consumer Model
Source: CIP4, JDF Specification, 2002, P. 51
43
CIP4, Job Definition Format, 2000, P. 4.
© 2003 by Catherine Dammann.
4 Data Exchange Formats
39
The output resource of one (producing) node becomes the input resource of the following (consuming) node where it is joined by further inputs resources. The node then
consumes them together. A node's execution only starts when all required input resources are available. At the beginning of the JDF job, the first input resources comprise the customer's artwork and further print instructions. The last executing process
of the job outputs the final resource, which is the desired product. This follows the principle: “The last process in a chain of processes defines the output resource of its parent process.”44
A node locally or globally references resources. “JDF nodes may only reference resources in the two kinds of locations: in the node’s own ResourcePool element or in
JDF nodes that are hierarchically closer to the JDF root.”45. Any referenced resource
should therefore be included in the ResourcePool element of the highest-level referencing node.
By specifying a resource’s class attribute, resources are categorized according to the
following:
• Consumable
o Consumable resources are consumed while process execution.
o Examples: ink, media (any printable surface such as sheet, film or plate)
• Handling
o Handling resources are consumed but not destroyed during processing.
o Examples: tools (such as an embossing stamp), sheet name
• Quantity
o Quantity resources are components that have been created from a Consumable or a previous Quantity resource.
o Examples: printed or processed material
• Implementation
o Implementation resources are the employees and devices that control
and execute a node.
o Examples: employee information (such as personal ID and shift), information about certain device capabilities (such as device ID, manufacturer name or model number)
• Intent
o Intent resources define the details of a product to be produced. Intent
resources are recognised by appending the suffix “Intent” to their name.
o Examples: ColourIntent, FoldingIntent, DeliveryIntent
44
45
CIP4, JDF Specification, 2002, P. 52.
Ibid., P. 49.
© 2003 by Catherine Dammann.
4 Data Exchange Formats
40
• Parameter
o Parameter resources define process details and non-physical computer
data. They are usually linked to a specific process. Intent resources are
often transferred to Parameter resources during the production process.
Parameter resources are recognised by appending the suffix “Params”
to their name.
o Examples: Content files, InkZoneCalculationParams for the InkZoneCalculation process
• PlaceHolder
o PlaceHolder resources are not actual entities but placeholders for resources that are added during processing. This enables the creation of a
JDF job including process linking without accurately knowing all job and
process details. “Using PlaceHolder resources, a processing skeleton
can be constructed that gives a basic shape to a job. The appropriate
resources can be substituted for PlaceHolder resources when they become known.”46
The definition of physical resources (Consumable, Handling and Quantity) can be used
for bridging JDF enabled systems to enterprises' inventory management systems.
Real-time consumption data empowers the print shop to perform just-in-time ordering
of stock.
Resources are bond to nodes with ResourceLinks that “describe what resources a
node uses, and how it uses them.”47 This means, ResourceLinks specify the resource's
usage as input or output of a particular node. The resource dependencies resulting
from the producer/consumer model implicitly link the nodes of one JDF job. With the
use of ResourceLinks as a means for process management, “the combination of hierarchical nesting of nodes and lateral linking allows complex process networks to be
constructed.”48 Figure 23 and 24 show the hierarchical tree structure of a job and the
corresponding process chain.
46
CIP4, JDF Specification, 2002, P. 48.
Ibid., P. 50.
48
Ibid., P. 28.
47
© 2003 by Catherine Dammann.
4 Data Exchange Formats
41
Figure 23: A Hierarchical Tree of JDF Nodes
Source: CIP4, JDF Specification, 2002, P. 16
Figure 24: A JDF Process Chain Linked by Input and Output Resources
Source: CIP4, JDF Specification, 2002, P. 17
A job’s process sequence is individually established by the respective MIS considering
local constraints, such as transport distances between machinery, load capabilities or
time requirements.
ResourceLinks are recognised by the suffix 'Link' in the respective ResourceLink name.
They are either internal links, linking to resources within the same JDF document or external links, linking to objects outside of it.
© 2003 by Catherine Dammann.
4 Data Exchange Formats
42
Deriving from the resource class, there are seven abstract ResourceLink elements:
•
•
•
•
•
•
•
3
PlaceHolderLink
ImplementationLink
ParameterLink
IntentLink
HandlingLink
QuantityLink
ConsumableLink
Workflow Components
The following components manage the workflow of a JDF job. These components are
logical functions implemented in automated tools or embedded in the print shop’s software such as in TWS or MIS. Some components may be integrated in one function
such as employing a controller with agent properties.
• An agent is any tool that composes JDF. It reads and writes JDF resulting in “the
ability to create a job, to add nodes to an existing job, and to modify existing
nodes.”49 The agent must therefore know all local constraints and process sequences as they determine the workflow as they write/modify the JDF file.
• A controller routes JDF information to the correct devices. In a workflow, it may
be integrated in a controller network with lower level sub controllers. If this is the
case, controllers may communicate not only with devices but also with each
other. The communication occurs through JMF.
• A device reads and interprets JDF. It executes the JDF information in instructing
machines to perform the physical execution. Devices are proprietary to the respective equipment.
• A machine in a JDF workflow does not understand JDF. Machines are not only
physical equipment such as a press or hardware RIP but also controlling software
or computer workstations without their own JDF interface. “A machine is any part
of the workflow system designed to execute a process.”50
• The MIS oversees the JDF workflow. It dictates and monitors the execution of all
processes through communication with the production facilities. It either uses the
JMF mechanism for real time information or collects performance data contained
in the JDF file for job tracking and accounting.
49
50
CIP4, JDF Specification, 2002, P. 11.
Ibid., P. 11.
© 2003 by Catherine Dammann.
4 Data Exchange Formats
43
Figure 25 shows an example of JDF and JMF workflow interactions.
Figure 25: JDF and JMF Workflow Interactions
Source (based on): CIP4, JDF Specification, 2002, P. 13
As mentioned above, JDF does not require a particular workflow. Its flexibility allows it
to model existing standard workflows as well as highly customised ones in interlinking
the required nodes for printing a product. “JDF is equally as effective with a simple system using a single controller-agent and device as it is with a completely automated industrial press workflow with integrated pre- and postpress operations.”51 JDF provides
four basic combinable process-routing mechanisms:
• Serial processing. Subsequent processing, represented by a single process
chain.
• Overlapping processing. Simultaneous processing with the help of pipe definitions.
• Parallel processing. Parts of the JDF tree are spawned for independent processing and merged back.
• Iterative processing. Repeated circular processing.
4
Job Messaging Format
JMF is a subset of JDF providing a messaging architecture that enables communication and interaction between controllers and devices on the shop floor and to the MIS.
51
CIP4, JDF Specification, 2002, P. 13.
© 2003 by Catherine Dammann.
4 Data Exchange Formats
44
The message model of JMF is based on the IMF message mechanism. JMF enables
monitoring resource consumption, controlling process execution and exceptions, realtime device queries on process status (i.e. job tracking functionality) and job scheduling.
JMF has a different structure than JDF. Its root node is a JMF element that “contains a
series of predictable attributes and instances of Message elements.”52 The Message
elements represent these standard message types:
• Signal: unidirectional status change information sent to a series of controllers,
such as process begin or completion.
• Query: bi-directional information request from a controller such as current JobID
and job progress or queued JobIDs.
• Command: an instruction sent to the controller such as to interrupt or restart the
job or change job priorities in the queue.
• Response: a controller's direct answer to a query (containing the requested information) or a command (informing that the command has been received and interpreted).
• Acknowledge: a delayed response to notify of completion or result of a command of long latency.
Following is an example of how these messages may be used: “The workflow system
can tell the folding machine to resume processing its input queue, i.e. get back to work
on the jobs that have been sent to it and ‘inform me when you are up and running’. The
folding controller sends a response that it got the command and is working on it and
that it will send an Acknowledge. Once the command has been executed and the machine is running, the controller sends an Acknowledge back to the workflow system.”53
The entire workflow system must be integrated in a Local Area Network (LAN) for using
JMF. The JMF messages are transferred through the LAN via Hypertext Transfer Protocol (HTTP). An HTTP/JMF messaging channel may also be used for JDF file submission to controllers.
4.2.2.4
Market Analysis of Implementation
The market analysis presents the adoption of JDF in the commercial printing industry.
“No printing or graphics enterprise is going to benefit from JDF integration until equipment and systems manufacturers offer true JDF compliant products, and no equipment
and systems manufacturers are going to offer JDF compliant products until printing en-
52
53
CIP4, JDF Specification, 2002, P. 107.
TripleArc, Job Messaging Format, 2002, P. 6.
© 2003 by Catherine Dammann.
4 Data Exchange Formats
45
terprises begin to demand JDF.”54 The current prevalence of JDF in software applications is presented. These results are based on Internet research and e-mail correspondence with software vendors in October 2002. The print shops’ demand for JDF is
examined. These results are based on primary data gained by an e-mail questionnaire
in September and October 2002.
1
Software Applications
The first software applications with JDF functionality entered the market at the end of
2001. Besides JDF compliant software for specific processes (such as ink setting or
remote proofing), the following software applications have currently implemented JDF
functionality:
Agfa Apogee Series 3
The PDF-based TWS has implemented JDF since the beginning of 2002. Its modules
allow the creation of PDF files and JDF job tickets, job management and final output to
film, plate or digital proofs. The job manager Apogee Pilot normalises PDF files into
"Certified PDF Digital Masters", imposes pages and lets user create JDF job tickets referencing PDF pages. Externally created JDF job tickets can be imported. Content
creators such as designers or advertising agencies using Apogee Create for PDF creation may submit a PJTF job ticket with it.
Creo (acquired ScenicSoft)
Creo’s products are grouped under the label Network Graphic Production Environment.
This is focussed on integrating production and business systems in the print process
through modulation and standardisation. Figure 26 illustrates JDF data flow within
Creo’s Network Graphic Production Environment.
54
O’Brien, The State of JDF, 2002.
© 2003 by Catherine Dammann.
4 Data Exchange Formats
46
Figure 26: JDF Data Flow within Creo Networked Graphic Production
Source: Creo, JDF: Standard Interconnectivity, 2002, P. 3
• Prinergy is a PDF-based prepress workflow solution. It is capable of importing
JDF job data from MIS systems. Furthermore, it uses JDF compliant export files
to exchange job data, imposition information and page assignment information.
Data is sent to the press in PPF via the module PrintLink.
• UpFront is production-planning software. The current version 1.6 is able to import
JDF files from a MIS. It can export JDF files with imposition data that it received
from Preps.
• Synapse Prepare allows content creators to create prepress ready PDF files that
match printer’s specifications. An upcoming release will feature a JDF-based jobticketing scheme that permits the transfer of page assignment (run list) information along with the PDF.
• Preps is imposition software that allows importing JDF files from MIS and exporting imposition data in JDF.
• Synapse Page Assigner allows a user to build run list info that is output in JDF.
• Synapse Link links MIS with prepress. An example of this is enabling the interfacing of Creo’s Prinergy with Printcafe’s MIS Hagen/OA. Time and cost information
about processes can be sent in JDF/JMF from Prinergy through Synapse Link to
MIS.
© 2003 by Catherine Dammann.
4 Data Exchange Formats
47
Fujifilm CelebraNT Extreme
This PDF-based prepress workflow software uses JDF as its internal job ticket format
and is able to import JDF files into its system.
Optichrome Computer Systems Limited Optimus2020
Optimus2020 consists of modules for order entry, work instruction, job tracking,
production control, costing, pricing, scheduling, invoicing, estimating, sales analysis,
purchase orders, processing, stock control and internet customer service. It is able to
create JDF job tickets and export them to TWS. The import of externally created JDF
job tickets into the system is planned.
Printcafe
• Prepress Connector transfers prepress cost and time data in JDF from a prepress
workflow solution to an MIS. It was introduced in April 2002.
• Press Connector integrates press consoles and Printcafe’s MIS. JDF job ticket information is sent from the MIS to the press and press status information is sent
back from the press to the MIS. The Press Connector was introduced in October
2002.
• Postpress Connector completes Printcafe’s range of data exchange software between MIS and production systems. A post press connector for connectivity between Printcafe’s MIS and bindery and finishing equipment will be introduced.
PrintCity
PrintCity is a strategic alliance of more than 40 companies from the graphic arts industry promoting complete printing solutions in open system architectures. At the IPEX
trade fair in April 2002 they presented the JDF-based workflow scenario Closed LoopOpen Systems. The example integrated the required systems on business and production level for completing different print jobs. It showed the automatic data exchange via
JDF (and partly via PPF) starting with price quotation, job moving along the business
and production chain and ending with delivery and invoice. The system was comprised
of the following components:
•
•
•
•
•
•
•
•
Agfa Delano, Project Management
Optimus2020, MIS
Agfa Apogee Series 3, Prepress production workflow
Creo UpFront, Production Planning
Creo Preps, Imposition
PPI GlobalTrack, Job tracking
MAN Roland PECOM, Press control network
MBO Data Manager, Data transfer between prepress and postpress
© 2003 by Catherine Dammann.
4 Data Exchange Formats
48
• Offset presses from MAN Roland, Shinohara and Manugraph
• Digital presses from MAN Roland (DICOWeb) and Oce (Demandstream)
• Finishing equipment from Wohlenberg, Kama, MBO, Hohner and Blumer
The following software vendors have announced releases of JDF-based products:
• DiMS!, MIS, introduced October 2002 at Graph Expo
• Heidelberg Prinect, MIS and production management, introduced October 2002
at Graph Expo: Printready 1.0 (PDF-based prepress workflow), planned next:
CP2000 Center (Machine Control Console), completely JDF-based in 2004
• Printplus, MIS, first JDF functionalities end of 2002
• Agfa Delano, Project Management, beginning of 2003
• Agfa ApogeeX, Prepress workflow, 2003
• PPI Media/MAN Roland PrintNet, Production planning and workflow suite, 2003
• Markzware: Markzscout, Prepress workflow, 2003/2004, Flightcheck, Preflight,
2003/2004, Hawkeye, Preflight, 2003/2004
• Creo Pandora, Imposition
• Electronics for Imaging Velocity OneFlow, Prepress workflow
2
Print Shops
The following results have been gained from a questionnaire that was conducted in
September 2002 to 371 print shops in Germany, England and the United States of
America. The questionnaire and a detailed statistical analysis are to be found in the
appendix.
Thirty-seven print shops (10%) responded to the questionnaire. Of these thirty-seven,
fifteen (4%) where either too small to fill out the questionnaire or did not have the time
to answer. Twenty-two (6%) of the total respondents filled out the questionnaire.
Fifty percent of the respondents do not use any electronic job ticket in their business.
The job description is usually entered in order management software and printed out
for further processing. Twenty-seven percent automatically transfer an electronic ticket
between divisions (as opposed to within a division). This illustrates the lack of automation through EDI in the printing process. Print shops have realised the potential of
automated data exchange. Fifty-five percent are interested in having a standardised
electronic job ticket. Seventy-three percent have heard of JDF, while half of those
aware of JDF have assigned the responsibility of monitoring its development to a
member of their organisation.
These results illustrate a split within the commercial printing industry. Print shops are
constantly seeking process automation through innovative technology. However, smalland medium-sized print shops do not have financial power or are not willing to risk be© 2003 by Catherine Dammann.
4 Data Exchange Formats
49
ing part of the early adopters of new technologies. Comments from the questionnaire
confirm this approach with the respondents mentioning satisfaction with limited
automation in production and existing system capabilities.
Other remarks refer to low profits in printing business. Profits between 1.5% and 3% of
turnover do not allow a quick turnaround in equipment. JDF needs to be outstanding
technology where investment in compliant solutions is justified by the respectively required Return on Investment (ROI). Twenty percent of the respondents indicate that
process re-engineering benefits have not yet been exploited, while twenty-eight percent
specify prepress streamlining as their priority. General comments received from the respondents included the following themes:
• JDF will only reach its full potential when the majority of software vendors have
implemented it.
• JDF is the future standard in Production Planning and Controlling Systems (PPS)
as it is the only format providing all of the required data.
• The complexity of JDF leads to doubts about its adoption.
• CIP4’s approach of implementing all aspects of the variety of print jobs in one format is inherently problematic.
• The speed of JDF development/implementation into software leads print shops to
believe that they will not adopt JDF workflows in-house for another ten years.
“A promising approach but unfortunately afflicted with many little problems, although it
is often pretended that everything works fine. PDF-data was also meant to work trouble-free, but how is it in reality?”55
3
Summary
Since the first software applications with JDF functionality entered the market in 2001,
2002 has shown headway in introducing more JDF-based software. The Graph Expo
trade fair in October 2002 featured JDF and CIP as core topics. With its amount of heterogeneous systems, PrintCity’s Closed Loop–Open Systems proved the feasibility of
networking systems through JDF. “ ‘PrintCity has been the pioneer in creating a working JDF solution’, said Rainer Kuhn, General Manager of PrintCity.”56
As efficiency impact of JDF is highest in prepress, the presently available JDF compliant software is focussed on this area. “JDF development at this point seems to consist
primarily of systems and equipment that merely import or export JDF, treating JDF as
55
Schatz, Manfred, Automatisierung, 2002, Original text: 'Ein zukunftsträchtiger Weg, leider
noch mit vielen kleinen Problemen behaftet, wenn auch an vielen Stellen so getan wird, dass
alles funktioniert, PDF-Daten sollten auch problemlos laufen - doch wie sieht es wirklich aus?'.
56
Printcity, Printcity, 2002, P. 3.
© 2003 by Catherine Dammann.
4 Data Exchange Formats
50
simply a file format. Several products are being tested for interoperability—to ensure
one can read the JDF exported by another and then export JDF that another can read.
But, at this stage, systems importing JDF translate it into their own proprietary formats
rather than directly using JDF internally. The holy grail, if you will, is for systems and
equipment vendors to create truly JDF-based systems and equipment that can utilize
JDF to its fullest.”57
Since major printing software vendors and large print shops are members of the JDF
developing associations such as CIP4, PrintCity, Euprima and PrintTalk, their mutual
work on JDF ensures meeting the print industry’s needs. However, “a couple of significant companies, such as MAN Roland, Komori, and Mueller Martini have been highprofile participants, but have not provided any information regarding their JDF product
plans.”58 Besides further JDF-based product announcements of major CIP4 members,
companies such as Agfa and Creo have already started basing a majority of their products on open standards. This is comprised of JDF for the job information and PDF for
print content. “What used to be a 'wait and see' approach has turned into a general acceptance that JDF is firmly fixed in the future of the print industry.”59
Print shops will consider implementing JDF when replacing equipment, although some
legacy systems can be upgraded with JDF/JMF enabled controllers. An individual cost
benefit analysis helps to judge the respective ROI. Small- and medium-sized printers
may decide to start streamlining specific processes whereas large printers may target
the entire print workflow. ET Heron, PrintWeek’s winner of the ‘Printer of the Year
award’ in England has already decided: “we want a JDF-based system to link all areas
of the factory”60. They are beta-testing Agfa’s Project Management Software Delano at
present.
Currently available JDF functionality, such as in Agfa’s prepress workflow software
Apogee Series 3 is hardly in use by print shops, according to Agfa Germany. This is
due to the missing JDF connection to other software solutions.61 On a business level,
currently only one MIS offers limited JDF compliance.
Eighty-six percent of the respondents of the questionnaire accept print orders through
Internet/e-mail. Automating business processes between e-print procurement software
57
O’Brien, The State of JDF, 2002.
Harvey, JDF: Where to Begin, 2002, P. 11.
59
O’Brien, The State of JDF, 2002.
60
Hearnden, ET Heron, 2002.
61
According to: Birreg, Pers. e-mail, 2002.
58
© 2003 by Catherine Dammann.
4 Data Exchange Formats
51
and the print shop by providing JDF-based purchase orders has potential. Moreover,
preliminary processes (such as an RFQ) and job accompanying processes (such as
proofing approvals) can be streamlined via JDF. The connection point for the respective JDF file at the print shop’s side is the MIS. Upcoming releases of JDF-based software include several MIS.
© 2003 by Catherine Dammann.
52
5 Business Data Exchange with the Print Shop
The EDI between e-print procurement software and a print shop can be based on the
exchange of business data in JDF. The flexibility of JDF allows defining a job in different ways. “A job may be so well defined before production begins that the system administrator only has to set the wheels in motion and let the job run its course. It may
also mean that the person submitting the job has only a general idea of what the final
product will look like and that modifications to the intent will be made along the way,
depending on the course of the job.”62 This results in these two ways of defining a job:
• The JDF job can be entirely defined upfront, with identifying and creating all required nodes (product, combined, process groups and process nodes) and resources.
• The JDF job can be broadly defined, specifying product information but omitting
process details. Along the workflow, valid data will be added to the JDF file.
In an e-commerce environment, the print broker who submits the job knows the final
product and may know the structure of some product components. He usually does not
have detailed knowledge of the production processes. The JDF agent that is part of the
print broker's e-print procurement application creates the initial JDF job specification
according to the available information. At the print shop, the received JDF file is completed by a number of JDF agents, providing the required process details. “This information may be added because an agent knows more about the process needs to
achieve some result specified in a JDF node than the original, creating agent knew.”63
5.1 Business Objects
Business process interaction takes place between print broker and print shop before a
job is finished, i.e. a product printed. Each process is represented by a business object.
The business objects in the commercial printing industry are defined as follows:
• RFQ: The print broker requests a quote for a job from the print shop. The RFQ
serves as a means for an unambiguous specification of the desired product, possibly including acceptable material or method variations. An RFQ may be sent for
a new product or may supersede an existing RFQ (i.e. Request for re-quote).
• Quote: The Quote is usually sent as response to the RFQ. It may consist of general price and billing information or of detailed process specifications with respective pricing. The business object Quote includes the re-quote variation.
A Quote may supersede a previous Quote prior to a print broker’s answer with a
Purchase Order or a new RFQ.
62
63
CIP4, JDF Specification, 2002, P. 14.
Ibid., P. 84.
© 2003 by Catherine Dammann.
5 Business Data Exchange with the Print Shop
53
• Purchase Order: The Purchase Order is usually sent as response to the Quote,
“but may be the initial document in a well-defined buyer / print supplier relationship or when ordering finished goods items.”64 A Purchase Order may supersede
an existing Purchase Order prior to the print shop’s order confirmation.
• Invoice: The Invoice is sent after job shipping or each time when specified job
progress has been made. Discounts or extra charges may be added.
• Order Confirmation: The Order Confirmation is the print shop's acknowledgement
of having received the Purchase Order. “It may contain information about expected due dates and final pricing that were undetermined at the time of the
quote.”65
• Order Cancellation: An Order Cancellation is sent when one party wants to cancel
the job. For cancelling only certain job parts, the party must sent a new RFQ,
Quote or Purchase Order that needs to be confirmed by the counter party.
• Refusal: A Refusal is the explicit decline of a Business Object. One party implicitly
declines a Business Object in letting it expire.
• Order Status Request: The print broker requests job status information from the
print shop.
• Order Status Response: The job status information is sent as response to an Order Status Request or automatically when specified job progress has been made.
• Proof Approval Request: Contains the location (per Multipurpose Internet Mail Extensions (MIME) or URL) of a soft proof for approval by the print broker (on the
print buyer's behalf) or by the print buyer himself.
• Proof Approval Response: “Contains buyer’s approval or denial of a proof”66.
Figure 27 illustrates the business objects and their data flow between a print Shop and
a print broker.This thesis examines RFQ, Quote, Purchase Order and Invoice, the core
business objects in an order cycle.
64
PrintTalk, PrintTalk, 2002, P. 5.
Ibid., P. 6.
66
Ibid., P. 6.
65
© 2003 by Catherine Dammann.
5 Business Data Exchange with the Print Shop
54
Figure 27: Commercial Print Industry Business Objects
Source: Author’s Figure
Business objects consist of two types of data: JDF product specification and metadata.
Metadata is “descriptive data that is not directly included in the content of a document”67. This includes customer information, financial information and the definition of
the business document type. The JDF product specification provides an unambiguous
specification of the product to be produced.
5.2 Product Specification
The product specification is created using the JDF construct 'Product Intent'. “‘Product
Intent’ describes what a job (or some aspect of a job) will look like when it is completed.”68 'Product Intent' embraces the creation of nodes of type product with resources of class Intent. When creating a JDF job, a hierarchy of JDF product nodes is
formed (see figure 28).
67
68
Ray, Learning XML, 2001, P. 328.
CIP4, JDF Specification, 2002, P. 84.
© 2003 by Catherine Dammann.
5 Business Data Exchange with the Print Shop
55
Figure 28: Product Nodes in the JDF Tree Structure
Source (based on): CIP4, JDF Specification, 2002, P. 14
“JDF contains a set of generic structures that may occur in any element of a JDF […]
document. These are provided as containers for human-readable comments and descriptions”.69 They consist of a Comment text element that may be used for commenting to a particular attribute within the referencing element.70 Comment is specified by
defining attributes such as the language or name (of the attribute the comment refers
to). Besides Comment, optional relevant attributes of the generic structure are:
Name
Description
CommentURL
DescriptiveName
This URL links to an external element description.
A human-readable descriptive name for the element.
Table 2: Relevant Optional Attributes of the JDF Generic Structure
5.2.1 Final Product
5.2.1.1
Root Node
The JDF root node describes the final product to be printed. The following table shows
the required71 attributes of any JDF node (including the JDF root node).
69
CIP4, JDF Specification, 2002, P. 30.
See section 2 Components in 4.2.2.3 Specification.
71
Creating agents determine if an element or attribute is required or optional by validating
against the JDF schema. 'Required' indicates that the attribute/element must appear in every
JDF node. 'Optional' indicates that the attribute/element is generally optional, but required under
certain circumstances.
© 2003 by Catherine Dammann.
70
5 Business Data Exchange with the Print Shop
56
Name
Values
Description
ID
'any unique ID'
Type
ID is the node’s unique identifier within
one JDF document. It is used for unambiguous reference by sibling and descendant nodes of the same job.
Type specifies the category of a node.
Product
ProcessGroup
Combined
‘Any process name’
Waiting (node may be executed but has Status identifies the status of a node.
not completed a test run)
TestRunInProgress
Ready (successful test run completion,
node is ready for execution)
FailedTestRun (test run failed)
Setup (node is currently set up)
InProgress (node execution in progress)
Cleanup (represented process by the
node is being cleaned up)
Spawned (node has been spawned. This
refers to the JDF Spawning and Merging
mechanism)
Stopped (pause, maintenance break or
breakdown, but node may be resumed
later)
Completed (node has been completely
executed)
Aborted (node has been aborted, no later
resume)
Pool (node processes partitioned resources 72)
Status
Table 3: Required Attributes of any JDF Node
The JDF root node also requires the definition of these attributes:
Name
Values
Description
Xmlns
'any URI referring to an XML namespace'
Defines the unique URI, declaring the default namespace for all descendant elements.
Specifies the node’s version referring to the
JDF specification.
Version is required in the JDF root node,
but optional in JDF child nodes.
Version ‘any JDF specification version number’
Table 4: Required Attributes of the JDF Root Node
72
See section 3 Partitioned Resources in 5.2.1.2 Resources.
© 2003 by Catherine Dammann.
5 Business Data Exchange with the Print Shop
57
Optionally, the following attributes may be included in any JDF node.
Name
Values
JobID
'any job number’
Description
This is the internal identification
number of the job-creating application, for instance the order number
of the e-print procurement application.
Version
‘any JDF specification version num- Specifies the node’s version referber’
ring to the JDF specification.
Version is optional in JDF child
nodes, but required in the JDF root
node.
Activation
Default value:
Definition of a node’s activation
Active (node may be executed when status.
all inputs are available and all outputs are completely defined)
Other permitted values:
Inactive (set for prohibition of a
node’s execution or test run)
Informative (the job specification is
for information only)
Held (held execution)
TestRun (the node requires a test
run by a controller or device)
TestRunAndGo (automatic start if a
test run has been completed successfully)
JobPartID
‘any job part ID’
This is used by the job creating application if a job is split into parts. It
references to the job part.
ProjectID
‘any project ID’
The job creating application can define a project context to which the
job belongs.
SettingsPolicy Default value:
This indicates what the JDF agent
BestEffort (substitute or ignore
requests from a JDF consumer if
those settings and proceed execuunsupported settings appear.
tion)
Other permitted values:
MustHonor (reject the job)
OperatorIntervention (Pause the job
and query a device’s operator)
Table 5: Optional Attributes of any JDF Node
The required attributes for the JDF root node need to be set according to the following:
•
•
•
•
Type is set to Product.
Status is set to Waiting.
Xmlns declares the JDF namespace: http://www.CIP4.org/JDFSchema_1_1.
Version is currently only allowed to be set to 1.1 (the current version of the JDF
specification).
Optionally, these attributes may be set:
© 2003 by Catherine Dammann.
5 Business Data Exchange with the Print Shop
58
• JobID is the internal order number of the job creating application, i.e. the e-print
procurement application.
• ProjectID may be set if the order belongs to a contract of a bigger volume
(such as a Christmas greeting cards order as part of an order of printed goods related to Christmas).
5.2.1.2
Resources
Each JDF node holds a ResourcePool element containing single input and output resource elements. ResourcePool holds a parent abstract resource element. Children
inherit the parent’s attributes. The following table provides the required attributes of the
abstract resource element.
Name
Values
Description
ID
'any resource ID’
Class
Consumable
Handling
Quantity
Implementation
Intent
Parameter
PlaceHolder
Incomplete
Unavailable
InUse
Draft
Complete
Available
Unique identifier of a resource. Used for unambiguous reference by ResourceLinks.
See section 2 Components in
4.2.2.3 Specification.
Status
Indicates the status of the resource, i.e. the availability for
the referencing node.
Table 6: Required Attributes of the Abstract Resource Element
ResourcePool of the JDF root node holds two basic resource types:
• The resource that defines the output of the root node, i.e. the final product.
• The Intent resources as input resources, specifying the production of the root
node's output.
1
Output
Since the final product is produced via various input resources (e.g. ink, paper, artwork), the output resource is a Component.
© 2003 by Catherine Dammann.
5 Business Data Exchange with the Print Shop
59
The following table shows its required attributes.
Name
Values
ComponentType Ribbon
Sheet
Block
PartialProduct
FinalProduct
Description
This attribute categorizes the component.
Table 7: Required Attributes of a Component Resource
The product the Component represents may be specified in ProductType (examples:
book, business card, brochure, cover). Component may inherit further content from an
abstract physical resource element. These includes:
• Amount-the resource amount that is available. Amount does not specify the final
production amount, which is specified in the respective ResourceLink.
• Location-the resource’s location (e.g. for a warehouse system).
The required attributes of a Component need to be set to:
• Class. This is set to Quantity because it is a physical resource.
• Status. This is set to Unavailable, indicating that the resource is not ready to be
used (the product has not been printed yet).
• ComponentType. This is set to FinalProduct.
2
Input
Specifications for the production of the Component are given as Intent resources. “Intent resources define the details of products to be produced without defining the process to produce them.”73 “In contrast to process resources that define precise values, intent resources allow ranges or sets of preferred values to be specified.”74 For each
node of type product, there can only be one Intent resource. An exception to this restriction is the DeliveryIntent resource.75
The current JDF specification names sixteen different Intent Resources:
ArtDeliveryIntent
This resource specifies the artwork delivery to the print shop for further processing by
its prepress department. The attributes and elements contained in
ArtDeliveryIntent allow values setting for different artwork types. Depending on
the delivery of either digital or physical media, several settings can be applied:
73
CIP4, JDF Specification, 2002, P. 47.
Ibid., P. 84.
75
See section: 1 RFQ in 5.3.2.2 Business Object Elements.
74
© 2003 by Catherine Dammann.
5 Business Data Exchange with the Print Shop
60
• Physical media (such as a film): size and type, colour type(s), polarity or resolution.
• Digital media (files): amount of files, file type, creator application, options for
multi-document files, execution of a pre-flight process before file submission or
mapping of pages in the file to pages of the final product.
Details of the delivery of the artwork can be specified. This includes latest delivery date
and time, contact details of the involved parties (e.g. the print buyer's advertising
agency), artwork handling after usage (if it is returned to the customer or archived),
transfer (if the print shop picks it up or the print buyer delivers it), delivery method (e.g.
mail, digital or express) and details of payment. If any intermediate material is produced during print production (such as film, proofs or a plate), the handling of these
items can be specified (e.g. ownership or delivery to the print buyer).
BindingIntent
This resource specifies the binding parameters of a printed product. The binding type
can be determined (e.g. gluing, ring binding, stitching) as well as the material and colour for the binding and back cover. Specification of the binding process includes the
amount of components that are to be bound together, their orientation and the binding
side (top, bottom, left, right).
ColourIntent
This resource specifies the colour settings for the product. Beside determination of the
colour process standard (e.g. Cyan, Magenta, Yellow, Key (Black) (CMYK) or Hexachrome) and the ink manufacturer, possible coatings (material of layer on ink, e.g. varnish or silicone) can be specified.
DeliveryIntent
This resource specifies details for the delivery of the final product or a proof.76
EmbossingIntent
This resource specifies details of a job's embossing or stamping. Besides the embossing type (such as blind or foil embossing), settings for the direction of the image, the
transition between the embossed surface and the surrounding media and the height of
the different levels (vertical distance between the highest and lowest point of the
stamp) can be determined.
FoldingIntent
This resource allows the specification of folding options. One can define individual folding options or can reference predefined folding sequences from a folding catalogue.
76
See section: 2 Delivery in 5.3.1 JDF Job Specification.
© 2003 by Catherine Dammann.
5 Business Data Exchange with the Print Shop
61
Individual folding options comprise the amount of folds, their height and width and direction (for instance from the front page downwards).
HolemakingIntent
This resource allows specifying details for a hole making process. One can define individual holes, individual line hole punching sequences or can reference predefined hole
patterns from JDF's hole pattern catalogue. Specifying an individual hole includes the
size (in points), the position of the centre (relative to the coordinate system of the respective Component), the shape (elliptic, round or rectangular) and position.
InsertingIntent
“This resource specifies the placing or inserting of one component within another, using information that identifies page location, position and attachment method.”77 After
specifying the receiving component, the components that are to be inserted are
mapped according to their order in the ResourceLinkPool element. To be specified values include items such as inserting method (loose or with permanent or removable
glue) or a rotation applied to an inserting sheet before inserting.
LaminatingIntent
This resource allows the specification of lamination of a product. Values to be specified
are laminating temperature (hot or cold), the surface to be laminated (front, back or
both) and the thickness of the laminant (in micron).
LayoutIntent
This resource specifies the imaging of pages onto finished media and records the size
of the finished pages for the product component. The size (width and height) refers to
the finished sheets before and after folding not to the production sheet coming out of
the press. It furthermore includes the orientation of the finished media (portrait or landscape), the number of page sheets of the product component, the number of nonidentical pages and determines if contents are printed one sided or double sided.
MediaIntent
This resource allows the specification of the media type to be used for the component.
“In some cases, the exact identity of the medium is known, while in other cases, the
characteristics are described and a particular stock is matched to those characteristics.”78 If the identity of the media is known, the brand name can be specified. Characteristic specifications comprise the media type (default value: paper), the media colour,
grade and texture, the media thickness (in micron), the media weight (in grams per
77
78
CIP4, JDF Specification, 2002, P. 223.
Ibid., P. 227.
© 2003 by Catherine Dammann.
5 Business Data Exchange with the Print Shop
62
square metre (gsm), front and back coatings (glossy, satin), the size of the media (in
pt). One can also specify that the print buyer will supply the desired media.
NumberingIntent
“This resource describes the parameters of stamping or applying variable marks in order to produce unique components, for items such as lottery notes or currency.”79
Specifications include the numbering position on the page, the numbering colour and
the step, which is the distance between two subsequent numbers.
PackingIntent
This resource specifies packing parameters for shipping purposes. “The model for
packaging is that products are wrapped together, wrapped packages are placed in
boxes, boxes are placed in cartons, and cartons are stacked on pallets.”80 Options include the determination of the amount of product units per wrapped package, in each
box, in each carton and per pallet. One can also specify the box and carton shape
(length, width and height in points), the carton and pallet maximum weight (in kilograms) and the pallet type (for instance standard Euro pallet).
ProductionIntent
This resource allows the specification of general manufacturing instructions such as
the preferred process (Lithography, Flexography, Sheet) and requirements for quality,
speed and cost (Default: Balanced. Other possible values are: Cost effective, Fastest
and Highest Quality).
ProofingIntent
This resource allows the specification of proof desirability and proofing parameters if a
proof is required. Parameters include the amount of proof copies, the colour quality
(basic colour or accurate colour matching proof), the URL of a remote proofing device,
the proof creating technology (such as laser or soft proof) and the proof type (such as
page or imposition proof). One option can be set for legally binding the proof's representation of the image to the final printed product mentioned in the contract.
ShapeCuttingIntent
This resource specifies form and line cutting parameters for special shapes. It allows
setting values for the cut type (full cut or perforation), the cut shape or the filling material for a shape (such as transparent foil for an envelope window).
79
80
CIP4, JDF Specification, 2002, P. 230.
Ibid., P. 231.
© 2003 by Catherine Dammann.
5 Business Data Exchange with the Print Shop
3
63
Partitioned Resources
JDF allows references of a resource subset. The parent element of the resource to be
partitioned has the common attributes and elements for the complete resource. The
specific variations of the resource parts are defined in resource child elements of the
same element name. Besides optional attributes, the partitioned parent resource requires PartIDKey for defining criteria (i.e. IDs) by which the child elements are partitioned. Each child element is required to have these IDs as attributes defining their individual values. The following example shows a partitioned resource:
<ExposedMedia ID="L1" Status="Available" PartIDKeys="Separation"...>
<!--This is the parent element-->
<ExposedMedia Separation="Cyan"/>
<ExposedMedia Separation="Magenta"/>
<!--These are partitioned resource parts, partitioned by Seperation-->
</ExposedMedia >
The corresponding ResourceLink81 for the partitioned resource references ID of the
parent resource and holds Part elements for each resource part. Each Part refers to
the respective resource part by defining the partitioning ID of the resource part’s parent
as an attribute.
4
Inter-Resource Linking
JDF allows resource referencing directly from other resources for the purpose of reusing existent information. Inter-Resource Linking is established in nesting a ResourceRef element into the referencing resource, pointing to the referenced resource.
“The ResourceRef ’s name is generated by appending the string 'Ref' to the [referenced] element name.”82 ResourceRef main attribute is rRef that points to ID of the
target resource. The following is an example of Inter-Resource Linking83:
<ResourcePool>
<Layout rRefs="res1 res2">
<!--This is a referencing Resource-->
<!--These are ResourceRef elements-->
<SheetRef rRef="res1"/>
</Layout>
<Sheet ID="res1">
<!--This is a referenced Resource-->
</ResourcePool>
81
See section 5.2.1.3 ResourceLinks.
CIP4, JDF Specification, 2002, P. 58.
83
Extract from: Ibid., P. 59.
82
© 2003 by Catherine Dammann.
5 Business Data Exchange with the Print Shop
5.2.1.3
64
ResourceLinks
Each Resource element requires the definition of a ResourceLink element indicating
the resource's usage. These ResourceLink elements are contained in a node's ResourceLinkPool. ResourceLinkPool holds a parent abstract ResourceLink element. Its attributes are inherited to the respective ResourceLink child element. The following table shows the relevant required attributes of the abstract ResourceLink.
Name
Values
Description
Usage
Input
Output
'The respective target Resource's ID'
Specifies the usage of a resource
within this node.
Links to the ID of the target resource.
rRef
Table 8: Relevant Required Attributes of the Abstract ResourceLink
As the JDF root node holds the Component and the Intent resources, its ResourceLinkPool must have a ComponentLink (a QuantityLink) and IntentLinks for each
of the defined Intent resources.
Usage for ComponentLink is set to Output. rRef is set to the resource's ID value. As
a QuantityLink, ComponentLink may have an additional attribute amount that indicates how many units of the resource are produced (for output usage) or consumed
(for input usage). A QuantityLink is a physical ResourceLink. It may inherit additional
attributes from the abstract physical ResourceLink element.
Usage for each IntentLink is set to Input. rRef is set to the resource's ID value.
IntentLinks inherit no additional parameters from the abstract Intent ResourceLink element.
5.2.2 Product Components
If the final product consists of more than one component, JDF child nodes of type
product are defined. Product components are distinguished by “a unique set of characteristic, such as different media, different physical size, or different color (!) requirements.”84 The number of product components determines the number of JDF child
nodes in one product hierarchy level and the total amount of levels. “The bottom-most
level of the product hierarchy represents portions of the product that are each homogeneous in terms of their materials and formats.”85
84
85
CIP4, JDF Specification, 2002, P. 15.
Ibid., P. 85.
© 2003 by Catherine Dammann.
5 Business Data Exchange with the Print Shop
65
Resulting from the restriction of at most one Intent resource per product node, several
product child nodes must be defined, if they require the same Intent resources. “If multiple product parts with different intents are required, each part has its own
'Product Intent' node.”86 If one product consists of multiple parts where each part needs
to be folded in a particular way (thus requiring more than one FoldingIntent), the
definition of product child nodes is required.
Defining attributes and elements of these nodes is according to the above description
of defining the JDF root node except for the attributes that only apply to the root node.
Type is set to Product, as product components are defined. In JDF child nodes, a
JobPartID may be set, e.g. referencing the root node's JobID plus a part number or
a part name.
The output resource of a JDF child node is also a Component of class Quantity. The
value of ComponentType, however, is PartialProduct. The input resources of a JDF
child node are the Intent Resources specifying the production of the child node’s
Component. They are defined according to the above descriptions.
ResourceLinkPool indicates the resources' usage as described above.
5.3 Metadata
Business object metadata in the commercial printing industry can be encoded in an
“XML envelope that contains JDF as a job description”87. Customer, delivery and
scheduling information is added to the JDF product specification forming the JDF job
specification. The XML envelope is defined in the interface specification PrintTalk. Alternatively, JDF provides structures for including business object metadata in the original JDF file.
5.3.1 JDF Job Specification
When defining the JDF job, the initial JDF product specification as described in 5.2.
Product Specification is embedded into JDF job data. In a hierarchical view, the initial
JDF root node (including possible child nodes) specifying the final product moves one
level down (i.e. the JDF root node becomes a nested JDF node). Figure 29 illustrates
the hierarchy of the JDF product definition and the JDF job definition after adding customer and delivery information.
86
87
CIP4, JDF Specification, 2002, P. 36.
Ibid., P. 85.
© 2003 by Catherine Dammann.
5 Business Data Exchange with the Print Shop
66
Figure 29: JDF Product Specification and JDF Job Specification
Source: Author’s Figure
1
Customer
The CustomerInfo element is a container element for customer data describing the
print buyer's details. “This element usually is specified in the uppermost JDF node.”88
The attribute CustomerID is the internal customer number of the job creator, i.e. the
print broker's e-print procurement application. Referring to the print buyer's internal systems, a CustomerOrderID may be included, referencing their internal order number
and CustomerJobName, naming the customer's name for the job.
Contact details are defined in Inter-Resource Linking to a Contact resource whose list
of ContactTypes must include Customer. Contact defines print buyer's details such
as the company's name, organisational unit (for instance procurement or marketing),
address and contact person. The provided structures are derived from the vCard format. vCard is a format for personal data exchange. In specifying other values for
ContactTypes, Contact can also be used to describe further contact information,
such as details of the accounting department or the administrator being responsible for
the job's execution.
rRefs of the parent CustomerInfo holds an array of all resource IDs that are referenced through Inter-Resource Linking within this element (thus pointing here to ID of
88
PrintTalk, PrintTalk, 2002, P. 16.
© 2003 by Catherine Dammann.
5 Business Data Exchange with the Print Shop
67
Contact). Inter-Resource Linking additionally requires a child element ContactRef.
Its rRef is then set to the ID of the linked resource (of Contact).
Customer data in JDF can be used as a means for Customer Relationship Management (CRM). Job status information can be submitted from production to CRM systems
and then to the print broker/print buyer.
2
Delivery
Delivery of the final product is defined by specifying DeliveryIntent. Besides Contact, DeliveryIntent is included as the only resource in the ResourcePool of the
JDF root node, describing, “how, when and where the desired product should be delivered to”89. DeliveryIntent as an input resource specifies the delivery of the output
resource (Component) of the nested JDF node (i.e. the initial product specification.)
DeliveryIntent includes job related options, such as amount of product copies and
pricing and payment details for the complete delivery, i.e. the final job price. Delivery
related options comprise the earliest and latest delivery date and time, delivery method
(mail, pickup), delivery charges, delivery address and further contact details.
DeliveryIntent also allows defining the time of transfer of ownership rights (when
leaving the print shop or when arriving at the print buyer).
DeliveryIntent requires the definition of a DropIntent child element describing
an individual drop of a delivery. Using multiple DropIntent elements allows specifying the delivery to multiple locations. “Attributes that are specified in a DropIntent element overwrite those that are specified in their parent DeliveryIntent element. If optional values are not specified, they default to the values specified in the DeliveryIntent.”90
Each DropIntent must have a DropItemIntent child element describing what
must be delivered to each location. The DropItemIntent refers via Inter-Resource
Linking with a ComponentRef to the Component. The attribute Amount may be used
for specifying the number of Component that is to be delivered to this location. If not
defined, it defaults to the total amount of Component being produced (defined in the
ComponentLink). If one job consists of multiple final products that are specified in
JDF child nodes (such as the same book in a hard cover and in a soft cover version),
several DropItemIntents in one DropIntent may be defined.
89
90
PrintTalk, PrintTalk, 2002, P. 15.
CIP4, JDF Specification, 2002, P. 218.
© 2003 by Catherine Dammann.
5 Business Data Exchange with the Print Shop
3
68
Scheduling
The NodeInfo element in the JDF root node defines scheduling data. Schedule specification may include setting planned start and end production dates as well as deadlines for the start and end of production. Consequences, such as job cancellation if a
deadline is missed, can also be defined. The earliest start and end date and time can
be specified. A job priority may be set, resulting in preferred print of a job with higher
priority before lower priority jobs. A resource Employee can be referenced for defining
details (such as name or employee ID) of the job creating person.
5.3.2 PrintTalk
The interface specification PrintTalk enables end-to-end connectivity during an entire
print order. “While JDF describes the piece to be printed, PrintTalk specifies the external communication of business processes between printer and buyer.”91 PrintTalk joins
Commerce Extensible Markup Language (cXML) and JDF to create business objects
for data exchange in the print industry. “cXML is a streamlined protocol intended for
consistent communication of business documents between procurement applications,
e-commerce hubs and suppliers.”92 The current cXML specification version is 1.2.008.
The current PrintTalk specification 1.1 defines the following business objects: RFQ,
Quote, Purchase Order, Order Confirmation, Cancellation, and Refusal. The remaining
business objects (Status Request, Order Status Response, Proof Approval Request,
Proof Approval Response and Invoice) will be described in detail in future specification
releases. In the following paragraph, the business objects representing a basic e-print
procurement order cycle are introduced. These are RFQ, Quote, Purchase Order and
Invoice.
5.3.2.1
Header and Request
The PrintTalk root element has these three attributes:
Attribute
Description
Version
payloadID
timeStamp
The version of the PrintTalk specification. Required.
A transport unique number for this business document. Required.
An optional value for the date and time the document was sent (in International Standards Organisation (ISO) 8601 format: YYYY-MMDDThh:mm:ss-/+hh:mm. This is local time with time zone offset from
Greenwich Mean Time).
91
92
PrintTalk, PrintTalk, 2002, P. 4.
Ariba, cXML FAQ, No publishing date.
© 2003 by Catherine Dammann.
5 Business Data Exchange with the Print Shop
69
Table 9: Attributes of the PrintTalk Root Element
The top two elements of any PrintTalk business object are Header and Request. “The
Header identifies the parties involved in this correspondence”93 whereas the Request
element contains the respective business object itself. Figure 30 gives a high-level
view of the PrintTalk structure.
Figure 30: A High Level View of the PrintTalk Structure
Source (based on): PrintTalk, PrintTalk, 2002, P. 7
Header requires three elements for identifying the involved parties.
Element
Description
From
To
Sender
The party the document comes from.
The recipient of the document.
The party sending the document, which is the print broker. Further intermediate procurement applications, such as CommerceOne may
change this value while submitting (To and From are not changeable).
Table 10: Elements of PrintTalk Header Element
93
PrintTalk, PrintTalk, 2002, P. 7.
© 2003 by Catherine Dammann.
5 Business Data Exchange with the Print Shop
70
Credential elements provide accurate identification and authentication of the respective party. The values of Credential depend on the transfer direction of the respective business object (RFQ is sent from print buyer to print shop whereas Quote is
sent from print shop to print buyer).
Credential has two attributes that can be specified. Domain (required) defines the
identity type (such as DNS if identification by a Domain Name Service address). Type
(optional) prevents ambiguous Credential if the same From or To element defines
multiple parties (example: a request from a marketplace might include two Credential for the marketplace and the member company within one To element. Credential elements then contain accurate identification by defining type, for instance with
a value of marketplace). “Credential contains an Identity element and optionally a
SharedSecret element. The Identity element states who the Credential represents,
while the optional authentication elements verify the identity of the party. The SharedSecret element is used when the Sender has a username/password combination that
the requester recognizes.”94 The actual trading partners must agree on the exact Credential structure, i.e. number of Identity elements, prior to their first business
transactions.
Sender holds an additional element UserAgent for unique identification of the sending application. It “consists of the software company name, product name, and version.
Version details can appear in parentheses.”95
Request contains a business object element and encapsulates the JDF job specification. All business objects elements are derived from a single abstract business object
element. “Additionally, each of these [Business Objects] extends the abstract [business
object] for individual items unique to that Business Object.”96 The abstract business object element requires these attributes:
Attribute
Description
AgentID
The unique identifier of the user that sent the document, e.g. the
sales rep of the print broker in an RFQ or the estimator of a print
shop in a Quote.
The display name of this user.
Sending date and time of this business object.
The unique identifier of the document (RFQ, Quote, Purchase Order, Invoice number).
AgentDisplayName
RequestDate
BusinessID
Table 11: Required Attributes of the Abstract Business Object
94
Ariba, cXML User’s Guide, 2001, P.39.
Ibid., P.95.
96
PrintTalk, PrintTalk, 2002, P. 10.
95
© 2003 by Catherine Dammann.
5 Business Data Exchange with the Print Shop
71
These attributes may be specified:
Attribute
Description
BusinessRefID
The unique identifier of the document to which this document refers (if applicable). A Quote, for instance, responding to an RFQ
refers here to the ID of the RFQ.
Optional ID for the use of the document's sender, e.g. an internal
system ID.
Display text for this business object.
AuxID
DescriptiveName
Table 12: Optional Attributes of the Abstract Business Object
5.3.2.2
1
Business Object Elements
Request For Quote
The RFQ business object element inherits attributes and elements from the abstract
business object element and defines the following attributes itself:
• Expires specifies the due date by which a responding Quote is expected to be
received. Required.
• Currency is the optional desired currency for the Quote (three-digit currency
definition according to ISO 4217).
• Estimate may be optionally set to request the responding Quote to be binding
(set to false) or estimated (set to true).
• ReplaceID is set if an RFQ supersedes another RFQ, referring to the
BusinessID of the superseded RFQ. “A document can only supersede a previous one of the same type, i.e. an RFQ can only supersede RFQs. Additionally,
superseding is only allowed as long as the RFQ to be replaced is pending, i.e.
that the counter party has not yet answered.”97
• ReorderID is optionally used when the RFQ is for a re-order. It contains a white
space separated list of previous Purchase Order BusinessID.
• JDF is a mandatory element, which is the root JDF node. It specifies the desired
product including additional customer, delivery and scheduling data as described
above in section 5.3.1. JDF Job Specification.
An RFQ may specify additional job options. “All intent resources share a set of subelements that allow a Request for Quote to describe a range of acceptable values for various aspects of the product. These elements, taken together, allow an administrator to
provide a specific value for the quote [a price].”98 There are ten different abstract span
elements:
Span Element Types
Description
DurationSpan
EnumerationSpan
IntegerSpan
Describes a set of duration values to define time frames.
Describes a closed list of enumerative values.
Describes a numerical range of integer values.
97
98
PrintTalk, PrintTalk, 2002, P. 11.
CIP4, JDF Specification, 2002, P. 194.
© 2003 by Catherine Dammann.
5 Business Data Exchange with the Print Shop
NameSpan
NumberSpan
OptionSpan
ShapeSpan
StringSpan
TimeSpan
XYPairSpan
72
Describes an extensible list of NMTOKEN values.
Describes a numerical range of values.
Defines a specific option with a Boolean value.
Describes a set of numerical value pairs.
Describes a set of string values.
Describes a set of date/time values.
Describes a set of XYPair values.
Table 13: Abstract Span Elements
The abstract span elements share the following attributes:
Attribute
Description
DataType
Priority
Defines the data type of the element’s span values. Required.
“Indicates the importance of the specific intent.”99
Optional.
Default value: None
Other permitted values:
Suggested - A different value of Actual to Preferred or one that is outside of Range will be accepted.
Required – “Actual must be equal to Preferred or within Range.”100
Actual
This is the actual value that has been selected for the quote. Optional.
Preferred
The preferred value of the print broker/print buyer submitting the RFQ.
Optional.
Range
Comprise all allowed values for the span. Exception: This value is not
part of an OptionSpan element. Optional.
Detail
OptionSpan contains this attribute instead of Range for information
about the option. Optional.
Table 14: Attribute Set of Abstract Span Elements
The following example shows the usage of span values in DeliveryIntent101:
<DeliveryIntent DescriptiveName="Delivery of samples to buyer, rest to mail house" ID="Deliv1"
Class="Intent" rRefs="Item01 Contact1 Contact2" Status="Available">
<Overage DataType="NumberSpan" Priority="Required" Preferred="5"/>
<!--Overage: Percentage by which actual count of delivered items may exceed ordered
quantity.-->
<Method DataType="NameSpan" Priority="Required" Preferred="1stClassMail"/>
.
.
</DeliveryIntent>
If the RFQ is desired to have a set of delivery options, “specifying multiple DeliveryIntent resources effectively requests multiple options of a quote.”102 These DeliveryIntent resources may be defined in the same JDF node. This is the exception to the
rule that each JDF node may only have one Intent resource of the same type.
99
CIP4, JDF Specification, 2002, P. 196.
Ibid., P. 196.
101
Extract from: PrintTalk, PrintTalk, 2002, P. 25.
102
CIP4, JDF Specification, 2002, P. 36.
100
© 2003 by Catherine Dammann.
5 Business Data Exchange with the Print Shop
73
In an RFQ, the attribute AdditionalAmount may be specified in DropItemIntent
for requesting pricing on additional product amounts (such as: 1000 books cost $30
500, additional 1000 books cost $20 500)
2
Quote
The business object element Quote is specified using the same set of individual attributes as the RFQ in the context of a Quote.
• Expires specifies the date until which a corresponding Purchase Order needs to
be received.
• Currency determines the currency of the Quote.
• Estimate determines whether the quote provides an estimated or binding price.
• ReplaceID may be set if the Quote supersedes an existing quote.
• ReorderID may be specified as white space separated list of BusinessID values of the Purchase Order (s) the Quote refers to. “In this scenario the Quote is
the starting point of the negotiation and is intended to lead to a re-order.”103
The JDF node holds the pricing within its DeliveryIntent. A Pricing element may
appear in DeliveryIntent as well as in each DropIntent and DropItemIntent
depending on the provided price structure depth and requested data by the RFQ, respectively. Pricing of DeliveryIntent defines the pricing of the entire delivery including information of all Pricing elements of DropIntent and DropItemIntent.
Pricing of DropIntent may define pricing of an individual drop to one specific location. Pricing of DropItemIntent may define pricing of each product that is part of
the parent DropIntent.
For one product, each Pricing may hold direct Pricing child elements for the definition of a complete price structure. Defining Pricing in DeliveryIntent, without further Pricing in DropIntent and DropItemIntent, could determine, for instance,
the entire price of a job including shipping. Direct Pricing child elements could separate the printing price from the shipping price. A Pricing child element of the printing
price could define the printing price per item. Alternatively, JDF's generic element Comment can be used for information regarding a given price.
Pricing has the following attributes and elements:
• Currency changes the default currency definition of the quote.
• Item names the item that the price is provided for (for instance: 7500 books inclusive (incl.). shipping).
• Price specifies the quoted price for the item amount.
103
PrintTalk, PrintTalk, 2002, P. 11.
© 2003 by Catherine Dammann.
5 Business Data Exchange with the Print Shop
74
• AdditionalPrice may be provided if requested by defining AdditionalAmount in the RFQ or added by the print shop itself.
• HasPrice may be used for items whose price is unknown (value: false) and
therefore has to be added to the quoted price (for instance, Value Added Tax
(VAT), when providing a net price).
• Payment can be used for the definition of payment details if the Quote leads to a
Purchase Order. Its child text element PayTerm may be used for defining terms
and conditions (may also be found in a Purchase Order or Invoice).
3
Purchase Order
A PurchaseOrder is similar to its counterpart Quote. It should not include any options that were specified in the RFQ. PurchaseOrder defines the following additional
attributes:
•
•
•
•
Estimate does not exist as only relevant for an RFQ or Quote.
Expires specifies the date until the Purchase Order is valid.
Currency indicates the currency used in the Purchase Order.
ReplaceID may be set if the Purchase Order supersedes an existing Purchase
Order.
• ReorderID may be specified as white space separated list of BusinessID values of the PurchaseOrder (s) this PurchaseOrder is based on.
• The JDF node is a complete job specification or describes “the ordering of finished goods in catalog (!) - based environments”104.
JDF also allows the simple acknowledgement of a given Quote by defining Accepted
in DeliveryIntent as true.
A child element of Payment in Pricing of DeliveryIntent is CreditCard. It may
be used for providing details of the credit card on which to bill (CreditCard may also
be found in an Invoice).
4
Invoice
After final printing or when reaching specific milestones of a job, the print shop creates
an Invoice. The PrintTalk specification states that the business object element Invoice will be described in detail in future releases of the specification. The following
paragraph therefore only depicts the basic structure of Invoice.
Invoice is similar to the PurchaseOrder the job is based on. The set of additional
attributes for this business object consists of:
• Expires that specifies the date until payment is expected.
• Currency that may indicate the currency of Invoice.
104
PrintTalk, PrintTalk, 2002, P. 12.
© 2003 by Catherine Dammann.
5 Business Data Exchange with the Print Shop
75
The JDF node contains all elements and pricing for the actual delivery, if already delivered. Additional charges for costs that may have appeared during the course of the job
are included.
5.3.3 JDF BusinessInfo
Business object metadata can also be specified in the JDF root node of the JDF document. It can be placed in the BusinessInfo child element of NodeInfo. “It is expected that JDF will be utilized in conjunction with other e-commerce standards, and
this container is provided to store the e-commerce information within JDF in case a
workflow with JDF as the root level document is desired.”105 The following example
shows the definition of business object metadata in PrintTalk and pure JDF code.106
PrintTalk code:
<PrintTalk>
<Header>...</Header>
<Request>
<RFQ AgentID="Lara" RequestDate="2002-04-05T1700-0800"
Expires="2002-04-15T1700-0800" Estimate="false" AgentDisplayName="Lara GarciaDaniels" Currency="EUR" BusinessID="RFQ_ID">
<JDF ID="ScreenTest" Type="Product" JobID="ScreenJob" Status="Waiting"
Version="1.1" xmlns="http://www.CIP4.org/JDFSchema_1_1">
<NodeInfo LastEnd="2000-12-24T06:02:42+01:00"/>
(…)
</JDF>
</RFQ>
</Request>
</PrintTalk>
Pure JDF code:
<JDF ID="ScreenTest" Type="Product" JobID="ScreenJob" Status="Waiting" Version="1.1"
xmlns="http://www.CIP4.org/JDFSchema_1_1">
<NodeInfo LastEnd="2000-12-24T06:02:42+01:00">
<BusinessInfo>
<Root>
<!--The root element of the employed e-commerce standard-->
(...)
</Root>
</BusinessInfo>
</NodeInfo>
(...)
</JDF>
105
106
CIP4, JDF Specification, 2002, P. 42.
Extract from: Ibid., P. 87.
© 2003 by Catherine Dammann.
76
6 Case Study
The case study describes the use of JDF and PrintTalk in a practical environment. After
depicting the print broker MagentaSoft (Pty) Ltd. with their e-print procurement application, JDF/PrintTalk implementation is illustrated.
6.1 MagentaSoft (Pty) Ltd.
6.1.1 The Company
MagentaSoft (Pty) Ltd.107 is a print broker offering traditional and e-print procurement to
medium and large enterprises. MagentaSoft (Pty) Ltd. is based in Johannesburg, South
Africa. It currently employs seven staff including working directors in Design, Sales,
Software Development and Operations. MagentaSoft (Pty) Ltd. acts as print
shop/provider towards the print buyer and as print buyer towards the print shop. The
business model is revenue-based. Income is generated by mark-up, as there are no
set-up or licensing costs for the e-print procurement application. The product scope
comprises all printed goods (black/white or colour) ranging from business cards and
letterheads to brochures, catalogues and financial reports. Three quarters of total
transactions are business cards, which are responsible for 20% of total turnover. The
other quarter comprises a variety of printed goods and is responsible for 80% of total
turnover.
6.1.2 Electronic Print Procurement Application
The e-print procurement application allows print buyers to typeset, proof and order their
print and promotional collateral via online access. Individual approval rules for e-mail or
online order approval can be defined. Process management will be facilitated in a future release in receiving status queries of job approval, rejection, process and delivery,
invoice and payment. The system consists of a number of modules. These include:
• Catalogue – an online aggregation of a print buyer’s print collateral. It presents
the user with a drill down facility to locate the collateral they wish to print.
• XML/PDL to PDF Engine - the core component that converts an XML document
to a print-ready PDF file. The XML document is a page description of the final desired output. It includes links to assets such as logos, fonts, colours, etc. Customisation of printed collateral is facilitated by online editing the XML/PDL document and then passing it through the XML/PDL to PDF engine to generate the
PDF file.
107
URL: http://www.magentasoft.com/
© 2003 by Catherine Dammann.
6 Case Study
77
• RIP – rasterises the PDF file into a raster file (JPEG). This file is displayed on the
website to proof the document.
• Imposition – imposition of multiple PDF files into one single imposed PDF file.108
• Approval Workflow Engine – an XML-based rules engine. Print buyers have an
XML encoded rules file, which is executed to control the workflow of their approval process.
• Order Entry Website – the print buyer interface with MagentaSoft (Pty) Ltd. The
website enables log in, users and groups, logging and order tracking. The Catalogue is presented within this website. It implements a graphical interface for editing the XML/PDL files as well as viewing the rasterised proofs. The site facilitates
order placement. Purchase orders are dropped into the Approval Workflow Engine for final approval.
• Administrative Website – an interface for MagentaSoft (Pty) Ltd. staff. They can
add and modify companies, users and collateral.
6.2 JDF/PrintTalk Implementation
This section contains data definition and encoded JDF/PrintTalk example for a print
job. The business object RFQ is presented here, while the JDF/PrintTalk encoded
business objects Quote, Purchase Order and Invoice are to be found in the appendix.
The workflow at the print shop is outlined when receiving a JDF/PrintTalk Purchase
Order.
6.2.1 Request for Quote Data Definition
EDI requires knowledge of the data structure. This section defines the data that MagentaSoft (Pty) Ltd. requires to be transferred via JDF to the print shop. Content data is
transferred in an imposed PDF file that is shown in figure 31.
108
See figure 31 for an image of an imposed PDF file.
© 2003 by Catherine Dammann.
6 Case Study
78
Figure 31: Extract of an Imposed PDF File
Source: MagentaSoft (Pty) Ltd.
The required administrative and product data is listed and matched to the respective
JDF/PrintTalk data field in the following table:
Administrative Data
Data field
(Structure: JDF/PrintTalk (PT) Element/Element…Attribute)
Document send date/time
PT PrintTalk…timestamp
Sender
PT From
Receiver
PT To
Application name
PT UserAgent
Name of MagentaSoft (Pty) Ltd. Account Man- PT RFQ…AgentID
ager
RFQ number (No).
PT RFQ…BusinessID
Expected date for the quote
PT RFQ…Expires
RFQ date
PT RFQ…RequestDate
Job no.
JDF JDF…JobID
Customer no.
JDF CustomerInfo…CustomerID
Delivery Method
JDF DeliveryIntent/Method and JDF DeliveryIntent/Transfer
Delivery Address
JDF Address
Name of MagentaSoft (Pty) Ltd. Production
JDF Person
Manager
Phone, Fax, E-mail of MagentaSoft (Pty) Ltd. JDF ComChannel
Production Manager
Location of PDF content file
JDF FileSpec…URL
Data description
Table 15: Administrative Data of an RFQ
© 2003 by Catherine Dammann.
6 Case Study
79
Product Data
Data description
Number of copies
Product size
Colours
Paper Weight
Paper Type
Data field
(Structure: JDF/PrintTalk (PT) Element/Element…Attribute)
JDF ComponentLink…Amount
JDF LayoutIntent/Dimensions
JDF ColourIntent
JDF MediaIntent/Weight
JDF MediaIntent/Stockbrand
Table 16: Product Data of an RFQ
6.2.2 Print Job “Business Cards”
The print job is as follows:
•
•
•
•
•
•
•
•
Product: business cards, 2 sided
Number of copies: 1400
Size: 55 x 85 mm
Colours: Pantone colour scheme, solid black and solid red
Paper: Chorus, gloss, 300 gsm
Finishing: laminated front, matt
Artwork: supply of an imposed PDF file
Delivery: to MagentaSoft (Pty) Ltd., Johannesburg, South Africa
Figure 32 shows a hierarchical view of the print job.
Figure 32: A Hierarchical View of the “Business Cards” Print Job
Source: Author’s Figure
6.2.2.1
Request for Quote in JDF/PrintTalk
The example shows a JDF/PrintTalk encoded RFQ. The original RFQ document is
shown in figure 33. It contains added key reference points that are cross-referenced in
the JDF/PrintTalk code.
© 2003 by Catherine Dammann.
6 Case Study
80
Figure 33: The Original RFQ Text
Source: MagentaSoft (Pty) Ltd.
© 2003 by Catherine Dammann.
6 Case Study
81
The in JDF/PrintTalk encoded RFQ:
<?xml version="1.0"?>
<PrintTalk version="1.1" payloadID="1023" timeStamp="2003-03-12T09:35:12+02:00"
xmlns="http://www.printtalk.org/schema" xmlns:jdf="http://www.CIP4.org/JDFSchema_1_1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<!--payloadID: unique transport ID of the message-->
<!--timeStamp: the RFQ sent date/time-->
<Header>
<From>
<!--1 From: the print broker-->
<Credential domain="magentasoft.com">
<!--MagentaSoft (Pty) Ltd. private registry-->
<Identity>Magentasoft</Identity>
</Credential>
</From>
<To>
<!--2 To: the print shop-->
<Credential domain="magentasoft.com">
<Identity>Law Printing</Identity>
</Credential>
</To>
<Sender>
<!--3 Sender: The print broker’s e-print procurement system-->
<Credential domain="DNS">
<Identity>magentasoft.com</Identity>
</Credential>
<UserAgent>MS E-Print 1.0</UserAgent>
<!--Identifies the software agent-->
</Sender>
</Header>
<Request>
<RFQ AgentID="Simon" AgentDisplayName="Simon Haskell" BusinessID="MSRFQ14203" Currency="ZAR" DescriptiveName="RFQ for business cards" Estimate="false"
Expires="2003-03-14T09:35:00+02:00" RequestDate="2003-03-12T09:35:12+02:00">
<!--4 AgentID: Unique identity of MS E-Print user who sent the document.-->
<!--5 BusinessID: Unique identifier of the RFQ-->
<!--Currency: Preferred currency for subsequent quote-->
<!--DescriptiveName: Human-readable display text-->
<!--Estimate: False, when the subsequent quote should be binding-->
<!--Expires: Due date/time for the subsequent Quote (here: 2 days from request date)-->
<!--6 RequestDate: Date/time of the RFQ-->
<JDF DescriptiveName="2-sided, 2-c business cards" ID="root" JobID="MS-BC-203"
Type="Product" Status="Waiting" Version="1.1"
xmlns="http://www.CIP4.org/JDFSchema_1_1">
<!--ID: Unique identifier of this JDF node-->
<!--7 JobID: sender's reference to a job.-->
<!--Version: JDF specification version.-->
<CustomerInfo CustomerID="MS-CU-2">
<!--8 Magentasoft (Pty) Ltd. internal customer-no. of the print buyer-->
</CustomerInfo>
<ResourceLinkPool>
<DeliveryIntentLink rRef="Delivery" Usage="Input"/>
<!--rRef: points to the ID of the DeliveryIntent resource-->
</ResourceLinkPool>
© 2003 by Catherine Dammann.
6 Case Study
82
<ResourcePool>
<DeliveryIntent ID="Delivery" Class="Intent" rRefs="BC Contact"
Status="Available">
<!--rRefs: points to the ID of the Contact resource and the ID of the output resource of the nested JDF node -->
<Method Datatype="NameSpan" Priority="Suggested"
Preferred="BestWay"/>
<!--9 Preferred: “BestWay” lets print shop decide on delivery method-->
<Transfer DataType="EnumerationSpan" Priority="Required"
Preferred="PrinterToBuyerDelivery"/>
<DropIntent>
<DropItemIntent>
<ComponentRef rRef="BC"/>
<!--Inter-Resource Linking to the Component to be delivered-->
</DropItemIntent>
</DropIntent>
</DeliveryIntent>
<Contact ID="Contact" Class="Parameter" Status="Available"
ContactTypes="Customer Delivery">
<ComChannel ChannelType="WWW"
Locator="http://www.magentasoft.com"/>
<Company OrganizationName="Magentasoft" ID="Company"
Class="Parameter" Status="Available"/>
<Address Street="57 Sloane Street" City="Bryanston" Country="South Africa"/>
<ExtendedAddress>1st Floor Wrigley Field, The Campus</ExtendedAddress>
<Person JobTitle="Production Manager" FirstName="Bronwyn"
FamilyName="Matthews">
<!--Person: a contact person-->
<ComChannel ChannelType="Phone" Locator="+27/(0)11-5750033"/>
<ComChannel ChannelType="Email"
Locator="mailto:bronwyn@magentasoft.com"/>
<ComChannel ChannelType="Fax" Locator="+27/(0)11-5760033"/>
</Person>
</Contact>
</ResourcePool>
<JDF ID="Sub1" Type="Product" Status="Waiting" JobPartID="MS-BC-203Cards">
<!--The node specifying the business cards-->
<ResourceLinkPool>
<ComponentLink rRef="BC" Usage="Output" Amount="1400"/>
<ComponentLink rRef="Front" Usage="Input"/>
</ResourceLinkPool>
<ResourcePool>
<Component ID="BC" Class="Quantity" Status="Unavailable"
ComponentType="FinalProduct" ProductType="Business Card">
<!--The final business cards-->
<!--Status: Unavailable as not printed yet-->
</Component>
<LaminatingIntent ID="Lam" Class="Intent" Status="Available">
<Surface DataType="EnumerationSpan" Priority="Required"
Preferred="Front"/>
<!--14 Only front side is laminated-->
<Comment>Please Matt Lamination</Comment>
</LaminatingIntent>
© 2003 by Catherine Dammann.
6 Case Study
83
<LayoutIntent ID="Size" Class="Intent" Status="Available"
Sides="TwoSidedHeadToHead">
<!---10 LayoutIntent: size of the cards-->
<Dimensions DataType="XYPairSpan" Priority="Required"
Preferred="85 55"/>
<!--Dimensions: landscape implied when X value > Y value-->
</LayoutIntent>
<ColorIntent ID="Col" Class="Intent" Status="Available">
<ColorStandard DataType="NameSpan" Priority="Required"
Preferred="Pantone"/>
<!--11 Pantone colour scheme-->
<ColorsUsed>
<SeparationSpec Name="485"/>
<SeparationSpec Name="Proc.Black"/>
</ColorsUsed>
</ColorIntent>
<MediaIntent ID="Pap" Class="Intent" Status="Available">
<Weight DataType="NumberSpan" Priority="Required"
Preferred="300"/>
<!--12 Weight: in gsm-->
<StockBrand DataType="StringSpan" Priority="Required"
Preferred="ChorusGloss"/>
<!--13 StockBrand: the paper brand-->
</MediaIntent>
<ArtDeliveryIntent ID="ArtFront" Class="Intent" Status="Available">
<ArtDelivery ArtDeliveryType="Digital Network" HasBleeds="true"/>
<RunListRef rRef="Run"/>
</ArtDeliveryIntent>
<RunList ID="Run" Npage="2" DocCopies="1" FirstPage="0" Sorted="true"
IsPage="true" PartIDKeys="RunPage">
<!--RunList: Ordered set of page description elements-->
<!--NPage: Total Number of pages-->
<!--PartIDKeys: Part ID by which the parts are seperated-->
<LayoutElement ElementType="Document"
IgnorePDLImposition="False">
<!--LayoutElement: Specifies the Document-->
<!--15 IgnorePDLImposition: PDF file does contain imposed pages-->
<FileSpec Application="MS E-Print 1.0" Compression="Deflate"
Disposition="Delete" FileSize="800000"
UserFileName="BusinessCards-Standard-Joe Smith"
URL="HTTP://www.magentasoft.com/pickup/law/MS-BC-203.zip"/>
<!--FileSpec: Represents the PDL file for LayoutElement-->
<!--Compression: Using ZIP public domain compression-->
<!--Disposition: executing device must delete file after completion-->
<!--16 URL: location of the zipped PDF file for download-->
</LayoutElement>
<RunList RunPage="0">
<!--RunPage: PartID as specified in PartIDKeys attribute of parent
RunList, refers to the first page (front) of the file-->
<LayoutElement ElementType="Page"
IgnorePDLImposition="False"/>
<!--LayoutElement: Specifies the page-->
</RunList>
<RunList RunPage="1">
© 2003 by Catherine Dammann.
6 Case Study
84
<!--RunPage: PartID as specified in PartIDKeys attribute of parent
RunList, refers to the first page (front) of the file-->
<LayoutElement ElementType="Page"
IgnorePDLImposition="False"/>
</RunList>
</RunList>
</ResourcePool>
<JDF ID="Sub2" Type="Product" Status="Waiting" JobPartID="MS-BC-203Front">
<!--The node specifying the front side-->
<ResourceLinkPool>
<ComponentLink rRef="Front" Usage="Output"/>
<ComponentLink rRef="Back" Usage="Input"/>
<LayoutIntentLink rRef="Size" Usage="Input"/>
<LaminatingIntentLink rRef="Lam" Usage="Input"/>
<!--Only a LaminatingIntentLink for the front side-->
<ColorIntentLink rRef="Col" Usage="Input"/>
<MediaIntentLink rRef="Pap" Usage="Input"/>
<ArtDeliveryIntentLink rRef="Art" Usage="Input"/>
<RunListLink rRef="Run" Usage="Input">
<!-- Link to the partioned RunList-->
<Part RunPage="0"/>
<!--Part: Link to the RunList part for the front-->
</RunListLink>
</ResourceLinkPool>
<ResourcePool>
<Component ID="Front" Class="Quantity" Status="Unavailable"
ComponentType="PartialProduct"/>
<!--ComponentType: PartialProduct for a product component-->
</ResourcePool>
</JDF>
<JDF ID="Sub3" Type="Product" Status="Waiting" JobPartID="MS-BC-203Back">
<!--The node specifying the back side-->
<ResourceLinkPool>
<ComponentLink rRef="Back" Usage="Output"/>
<LayoutIntentLink rRef="Size" Usage="Input"/>
<ColorIntentLink rRef="Col" Usage="Input"/>
<MediaIntentLink rRef="Pap" Usage="Input"/>
<ArtDeliveryIntentLink rRef="Art" Usage="Input"/>
<RunListLink rRef="Run" Usage="Input">
<!-- Link to the partioned RunList-->
<Part RunPage="1"/>
<!--Part: Link to the RunList part for the front-->
</RunListLink>
</ResourceLinkPool>
<ResourcePool>
<Component ID="Back" Class="Quantity" Status="Unavailable"
ComponentType="PartialProduct"/>
</ResourcePool>
</JDF>
</JDF>
</JDF>
</RFQ>
</Request>
</PrintTalk>
© 2003 by Catherine Dammann.
6 Case Study
6.2.2.2
85
Print Production
This section drafts a possible workflow at a print shop after receiving a JDF/PrintTalk
Purchase Order from the e-print procurement application. A print shop may have a
similar JDF system as shown in figure 34, as “the JDF standard does not dictate how a
JDF system should be built”.109
Figure 34: JDF System at a Print Shop
Source: European Print Management Association, Storyboard, 2002, P. 7
A series of JDF agents transform the received JDF file by inserting subsequent nodes
during processing. These nodes specify the process details for the print job. “The most
common instance of modification of a JDF job […] occurs during processing, when
109
CIP4, JDF Specification, 2002, P. vii.
© 2003 by Catherine Dammann.
6 Case Study
86
more detailed information is learned or understood and then added along the way”110.
Process details are captured in process group nodes and individual process nodes.
When all required input resources for a process node are specified and available, a
JDF controller routes the executable node to the executing device. Once the executing
device has completed outputting a resource, the JDF controller detects the next executable node and routes it to the correct executing device until the job is completed. “The
sequencing of events is controlled by the availability of input resources.”111
110
111
CIP4, JDF Specification, 2002, P 84.
Ibid., P 90.
© 2003 by Catherine Dammann.
87
7 Summary and Outlook
The problem this thesis addressed is the lack of integration of e-print procurement services into print production in the commercial printing industry. EDI of business data between an e-print procurement application and print shop needs to be established. Previously used file formats neither cover all job parameters nor handle specific data for
enabling e-commerce. This thesis analysed the usage of JDF as a suitable format for
EDI of business data in the commercial printing industry. The exchange of e-commerce
specific data was illustrated using the corresponding PrintTalk format. The case study
showed the practical implementation of JDF in an e-commerce environment.
JDF proved to be suitable for utilisation in e-print procurement applications. It allows
defining a print job with comprehensive parameters. Product data can be specified with
JDF 'Product Intent' and production data may be defined by including process parameters. Job metadata is included in JDF elements of the root node while PrintTalk defines
business object metadata for job submission. JDF provides the first means to eliminate
ambiguous job definitions in the commercial printing industry. This is a requirement for
efficient job processing through e-print procurement applications. In defining business
objects, PrintTalk provides business logic for EDI in the commercial printing industry.
Capturing the print buyer’s business documents in the e-print procurement application’s database enables efficient re-ordering. In archiving all job-related data of previously printed documents in JDF, re-runs can be efficiently processed. The automated
workflow enabled through a consistent JDF file ensures accurate re-execution of the
job. The use of JDF/PrintTalk for business data exchange and PDF for content data
exchange streamlines order processing. The designated e-commerce working group
within the CIP4 organisation shows the relevance of JDF/PrintTalk development for
building an e-commerce interface. As VDP emerges, JDF is the recommended job
ticket format in conjunction with the XML-based Personalised Print Markup Language
(PPML). While PPML specifies variable content for digital print, the embedded job
ticket refers to a JDF file.
Although schema validation facilitates software conformance to JDF, XML extensibility
and limits of XML schema may be the origin of interoperability issues. XML schema
has limits in covering all JDF aspects the specification requires. The JDF content
model cannot be fully matched. This affects the occurrence of more than one same
child element and JDF comment elements throughout the document. XML schema
does not provide context validation, i.e. ensuring that a job is defined according to print
© 2003 by Catherine Dammann.
Summary and Outlook
88
process understanding. Certain resources may be validly linked to a node, but may not
be appropriate for the product or process the node may represent.
Further JDF validation in software applications is required to ensure accurate JDF files.
The open source JDF API developed by CIP4 provides a C++ library of JDF classes
and a JDF parser supporting JDF specifics. Adobe Systems Incorporated has developed a JDF software development environment that provides C interfaces for creating,
manipulating and consuming JDF. The JDF Development Platform (JDP) by Objective
Advantage includes a schema-based JDF parser, a JDF object model and JDF storage
allowing parsed JDF nodes to be stored in a relational database.
JDF allows print shops and software vendors to create extensions that are unique to
their system by using their own namespace. Using private extensions can cause workflow and interoperability conflicts when third parties’ systems detect unsupported settings. Compliancy issues may arise from a JDF software implementation that concludes other actions from a valid JDF file than expected.
Beyond the business objects that are defined in the thesis, implementing online job
tracking via JDF/JMF status queries could be a further application of JDF for MagentaSoft (Pty) Ltd. A Magentasoft Pty (Ltd.) print supplier has started to implement JDF
by installing a JDF enabled printing device.
JDF/PrintTalk implementation in MIS is critical for considering it as the future business
data exchange medium in e-commerce. A JDF file specifying 'Product Intent' must be
completed by further JDF agents within order management and PPS before it can be
executed by JDF/JMF enabled devices in production. Currently available JDF compliant software was shown in section 4.2.2.4 Market Analysis of Implementation. PrintTalk
compliant products were shown at the GraphExpo in October 2002. In September
2002, Printable Technologies and PRISM USA announced the first PrintTalk integration
between a web-based print ordering system and MIS.
Print shops have to consider their JDF implementation strategy. Capital investment in
the commercial printing industry is intense. Print shops may want to replace equipment
over-time instead of re-engineering their print shop. “The industry must start using the
term “competitive life” and not “productive life” more often. Competitive life recognizes
the changes in the market and that the output competes with other media for the consideration of communication executives.”112 A print shop needs to document current
112
Webb, Ten Undeniable Trends, 2001, P. 7.
© 2003 by Catherine Dammann.
Summary and Outlook
89
systems and data flow to determine in which area JDF can be most beneficially used.
CIP affects not only technical implementation, but also organisational aspects. Task
and responsibility changes require staff training.
JDF implementation at the print shop may be accompanied by a complementary XMLbased implementation for data exchange to paper suppliers. PrintML, PML and PapiNet are XML-based languages for EDI between paper suppliers and print shops leading to a complete CIP concept at a print shop.
JDF is considered to becoming the industry standard for job ticket transfer. A narrow
definition for a standard could be: the technical specification of a voluntary set of rules
as the basis for systems to understand each other. The development of PDF in becoming the standard for content data transfer has shown that industry standards are created by market adoption. Wide software implementation and acceptance by print shops
are needed to make JDF a full standard for job ticket transfer in the commercial printing
industry. Self-commitments of several software vendors to develop JDF software and
CIP4’s comprehensive member list of industry leaders will support this goal. The market analysis showed a so far sceptical approach on the print shop side.
The Seybold Editors, a provider of news, consulting services and events for the printing
and publishing industry, nominated JDF as one of 'The Ten Biggest Technology Stories
of 2002'. “JDF may not be as headline-grabbing as a new press but it’s potentially the
most important development in the printing industry since Postscript.”113
113
TripleArc, A Guide to JDF, 2002, P.19, Quoting Eccles, Simon, Electronic Imaging Magazine.
© 2003 by Catherine Dammann.
90
Appendix
A1 Questionnaire ............................................................................................ 91
A2 Answer Analysis of Questionnaire ............................................................. 92
A3 Business Objects in JDF/PrintTalk ............................................................ 93
Quote ....................................................................................................... 93
Purchase Order .......................................................................................... 94
Invoice ...................................................................................................... 95
© 2003 by Catherine Dammann.
Appendix
91
A1 Questionnaire
Q1. Do you use electronic job tickets? (yes/no)
Q2. Which software/job ticket format is used by your company and in which division?
Business Division(Order Management, Accounting, Inventory):
Prepress:
Press:
Postpress:
Q3. Do you accept orders electronically (Internet/e-mail) (yes/no)
Q4. Is an electronic job ticket automatically transferred between divisions? (yes/no)
If yes, please specify between which divisions and how:
Q5. Would you be interested in having a standardised job ticket for the entire printing
process? (yes/no)
Q6. Which processes have the highest priority of being streamlined with electronic job
tickets (Data exchange to customer/prepress/press/finishing services)?
Q7. Have you heard of Job Definition Format (JDF)? (yes/no)
Q8. Have you assigned the responsibility of observing JDF-development to any company resource? (yes/no)
Q9. Have you got plans for implementing JDF within your company? (yes/no) If yes,
please specify.
Q10. Are you already using JDF compliant software? (yes/no). If yes, in which division,
which software products?
Further comments: (What do you think of the potential of JDF? Are you happy with the
existing job formats? What else would you like to mention concerning your workflow/JDF?)
© 2003 by Catherine Dammann.
Appendix
92
A2 Answer Analysis of Questionnaire
Question
Q1
Number
5
11
6
0
0
22
Question
Q7
Categories
Yes
No
Partly
No answer
Other
Total
Q3
Q4
Q5
Q10
%
%
%
%
%
Number
Number
Number
Number
23%
19
86%
6
27%
12
55%
3
14%
50%
3
14%
10
45%
7
32%
18
82%
27%
0
0%
4
18%
0%
0
0%
2
9%
0
0%
1
5%
0%
0
0%
0
0%
3
14%
0
0%
100%
22
100%
22
99%
22
101%
22
101%
Q8
Number
from
'yes' in
%
%
7.
Number
Number
16
73%
8
36%
8
6
27%
14
64%
8
0
0%
0
0%
0
0%
0
0%
22
100%
22
100%
16
Categories
Yes
No
Partly
No answer
Other
Total
Question
Q9
%
Number
%
from
from
from
'yes'
'yes' in 'yes'
in 7. Number
%
7.
in 7.
50%
3
14%
3
19%
50%
15
68%
10
63%
0%
1
5%
1
6%
3
14%
2
13%
100%
22
101%
16
101%
Q2
%
Categories
Number
MIS
7
28%
Prepress
3
12%
Press
0
0%
PostPress
0
0%
Comprehensive System
6
24%
Tailored Systems
3
12%
None
2
8%
No answer
4
16%
25
100%
Total
Question
Categories
To Customer
Prepress
Press
Postpress
All
Other
Total
Q6
Number
4
7
4
3
5
2
%
16%
28%
16%
12%
20%
8%
25
100%
Comment:
Q2 and Q6
Multiple answers were possible, total numbers therefore more than 22.
Q4, Q5, Q10 and Q9
Inaccuracies due to rounding differences.
© 2003 by Catherine Dammann.
Appendix
93
A3 Business Objects in JDF/PrintTalk
Quote
<?xml version="1.0"?>
<PrintTalk version="1.1" payloadID="1132" timeStamp="2003-03-14T08:16:01+02:00"
xmlns="http://www.printtalk.org/schema" xmlns:jdf="http://www.CIP4.org/JDFSchema_1_1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<Header>
<From>
<Credential domain="magentasoft.com">
<Identity>Law Printing</Identity>
</Credential>
</From>
<To>
<Credential domain="magentasoft.com">
<Identity>Magentasoft</Identity>
</Credential>
</To>
<Sender>
<Credential domain="DNS">
<Identity>law-printing.co.za</Identity>
</Credential>
<UserAgent>LP EasyQuote 2 .1</UserAgent>
</Sender>
</Header>
<Request>
<Quote AgentID="John" AgentDisplayName="John Miller" BusinessID="LPQUO-1704"
Currency="ZAR" DescriptiveName="Quote for business cards" Estimate="false" Expires="200303-21T08:15:59+02:00" RequestDate="2003-03-14T08:16:01+02:00">
<JDF DescriptiveName="2-sided, 2-c business cards" ID="root" JobID="MS-BC-203"
Type="Product" Status="Waiting" Version="1.1"
xmlns="http://www.CIP4.org/JDFSchema_1_1">
<CustomerInfo CustomerID="MS-CU-2"/>
<ResourceLinkPool>
<DeliveryIntentLink rRef="Delivery" Usage="Input"/>
</ResourceLinkPool>
<ResourcePool>
<DeliveryIntent ID="Delivery" Class="Intent" rRefs="BC Contact"
Status="Available">
<Method Datatype="NameSpan" Priority="Suggested"
Preferred="BestWay" Actual="Courier"/>
<Transfer DataType="EnumerationSpan" Priority="Required"
Preferred="PrinterToBuyerDelivery"/>
<Pricing Item="1400 Business Cards incl. Shipping" Price="4428.00"/>
<DropIntent>
<DropItemIntent AdditionalAmount="100">
<ComponentRef rRef="BC"/>
<Pricing Item="1400 Business Cards" Price="4200.00"
AdditionalPrice="200"/>
</DropItemIntent>
</DropIntent>
</DeliveryIntent>
<Contact ID="Contact" Class="Parameter" Status="Available"
ContactTypes="Customer Delivery">
<ComChannel ChannelType="WWW"
© 2003 by Catherine Dammann.
Appendix
94
Locator="http://www.magentasoft.com"/>
<Company OrganizationName="Magentasoft" ID="Company"
Class="Parameter" Status="Available"/>
<Address Street="57 Sloane Street" City="Bryanston" Country="South Africa"/>
<ExtendedAddress>1st Floor Wrigley Field, The Campus</ExtendedAddress>
<Person JobTitle="Production Manager" FirstName="Bronwyn"
Family-Name="Matthews">
<ComChannel ChannelType="Phone" Locator="+27/(0)11-5750033"/>
<ComChannel ChannelType="Email"
Locator="mailto:bronwyn@magentasoft.com"/>
<ComChannel ChannelType="Fax" Locator="+27/(0)11-5760033"/>
</Person>
</Contact>
</ResourcePool>
<JDF ID="Sub1" Type="Product" Status="Waiting" JobPartID="MS-BC-203Cards">
<!--The nodes specifying the Business Cards as in the RFQ-->
.
.
.
Purchase Order
<?xml version="1.0"?>
<PrintTalk version="1.1" payloadID="1242" timeStamp="2003-03-16T16:32:45+02:00"
xmlns="http://www.printtalk.org/schema" xmlns:jdf="http://www.CIP4.org/JDFSchema_1_1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<Header>
<From>
<Credential domain="magentasoft.com">
<Identity>Magentasoft</Identity>
</Credential>
</From>
<To>
<Credential domain="magentasoft.com">
<Identity>Law Printing</Identity>
</Credential>
</To>
<Sender>
<Credential domain="DNS">
<Identity>magentasoft.com</Identity>
</Credential>
<UserAgent>MS E-Print 1.0</UserAgent>
</Sender>
</Header>
<Request>
<PurchaseOrder AgentID="Simon" AgentDisplayName="Simon Haskell"
RequestDate="2003-03-16T16:32:45+02:00" BusinessID="MSPO-14203" Expires="2003-0318T16:32:00+02:00" Currency="ZAR" DescriptiveName="Purchase Order for business cards">
<JDF DescriptiveName="2-sided, 2-c business cards" ID="root" JobID="MS-BC-203"
Type="Product" Status="Waiting" Version="1.1"
xmlns="http://www.CIP4.org/JDFSchema_1_1">
<CustomerInfo CustomerID="MS-CU-2"/>
<ResourceLinkPool>
<DeliveryIntentLink rRef="Delivery" Usage="Input"/>
© 2003 by Catherine Dammann.
Appendix
95
</ResourceLinkPool>
<ResourcePool>
<DeliveryIntent Accepted="true" ID="Delivery" Class="Intent" rRefs="BC Contact" Status="Available">
<!--Accepted: A given quote is accepted without restating the job specification-->
Invoice
<?xml version="1.0"?>
<PrintTalk version="1.1" payloadID="1132" timeStamp="2003-03-31T08:16:01+02:00"
xmlns="http://www.printtalk.org/schema" xmlns:jdf="http://www.CIP4.org/JDFSchema_1_1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<Header>
<From>
<Credential domain="magentasoft.com">
<Identity>Law Printing</Identity>
</Credential>
</From>
<To>
<Credential domain="magentasoft.com">
<Identity>Magentasoft</Identity>
</Credential>
</To>
<Sender>
<Credential domain="DNS">
<Identity>law-printing.co.za</Identity>
</Credential>
<UserAgent>LP EasyQuote 2 .1</UserAgent>
</Sender>
</Header>
<Request>
<Invoice AgentID="John" AgentDisplayName="John Miller" BusinessID="LPINV-1847"
Currency="ZAR" DescriptiveName="Invoice for business cards" Expires="2003-0430T08:15:59+02:00" RequestDate="2003-03-31T08:16:01+02:00">
<JDF DescriptiveName="2-sided, 2-c business cards" ID="root" JobID="MS-BC-203"
Type="Product" Status="Completed" Version="1.1"
xmlns="http://www.CIP4.org/JDFSchema_1_1">
<CustomerInfo CustomerID="MS-CU-2"/>
<ResourceLinkPool>
<DeliveryIntentLink rRef="Delivery" Usage="Input"/>
</ResourceLinkPool>
<ResourcePool>
<DeliveryIntent ID="Delivery" Class="Intent" rRefs="BC Contact"
Status="Available">
<Method Datatype="NameSpan" Priority="Suggested"
Preferred="BestWay" Actual="Courier"/>
<Transfer DataType="EnumerationSpan" Priority="Required"
Preferred="PrinterToBuyerDelivery"/>
<Pricing Item="1400 Business Cards incl. Shipping and 14% VAT"
Price="5047,92">
<Pricing Item="1400 Business Cards" Price="4200,00"/>
<Pricing Item="Shipping" Price="228,00"/>
<Pricing Item="14% VAT" Price="619,92"/>
<Payment>
<PayTerm>2% 10 days, Net 30 days</PayTerm>
</Payment>
© 2003 by Catherine Dammann.
Appendix
96
</Pricing>
<DropIntent>
<DropItemIntent>
<ComponentRef rRef="BC"/>
</DropItemIntent>
</DropIntent>
</DeliveryIntent>
<Contact ID="Contact" Class="Parameter" Status="Available"
ContactTypes="Customer Delivery">
<ComChannel ChannelType="WWW"
Locator="http://www.magentasoft.com"/>
<Company OrganizationName="Magentasoft" ID="Company"
Class="Parameter" Status="Available"/>
<Address Street="57 Sloane Street" City="Bryanston" Country="South Africa"/>
<ExtendedAddress>1st Floor Wrigley Field, The Campus</ExtendedAddress>
<Person JobTitle="Production Manager" FirstName="Bronwyn"
Family-Name="Matthews">
<ComChannel ChannelType="Phone" Locator="+27/(0)11-5750033"/>
<ComChannel ChannelType="Email"
Locator="mailto:bronwyn@magentasoft.com"/>
<ComChannel ChannelType="Fax" Locator="+27/(0)11-5760033"/>
</Person>
</Contact>
</ResourcePool>
</JDF>
</Invoice>
</Request>
</PrintTalk>
© 2003 by Catherine Dammann.
Bibliography
Adobe Systems Inc. (Issuer): PDF for Prepress Workflow and Document Delivery, San Jose (United States (US)) 1997,
http://www.adobe.com/products/extreme/
pdfs/PDFPrepressWorkflow.pdf [14. Feb. 2003].
Adobe Systems Inc. (Issuer): Adobe PostScript Extreme, Adobe Solutions for
Commercial Printing, San Jose (US) 1998, http://www.adobe.com/
products/extreme/pdfs/extremewp.pdf [14. Feb. 2003].
Adobe Systems Inc. (Issuer): Portable Job Ticket Format, Technical Note No.
5620, San Jose (US) 1999, http://partners.adobe.com/asn/developer/pdfs/
tn/5620.pjtf.pdf [14. Feb. 2003].
Adobe Systems Inc. (Issuer): PDF Reference, third edition, Adobe Portable
Document Format, Version 1.4, San Jose (US) 2001,
http://partners.adobe.com/asn/developer/acrosdk/docs/filefmtspecs/
PDFReference.pdf [21. Mar. 2003].
Agfa-Gevaert N.V. (Issuer): Digital Roadmaps, Part 3: PDF Workflows, No
publishing place 1998, http://www.agfa.com/roadmaps/whitepapers/
03_pdf.pdf [10. Sept. 2002].
Ariba Inc. (Issuer): cXML User’s Guide, No publishing place 2001,
http://xml.cxml.org/current/cXMLUsersGuide.pdf [05. Mar. 2003].
Ariba, Inc. (Issuer): cXML FAQ, No publishing place and date,
http://www.cxml.org/prnews/faq.cfm [17. Feb. 2003].
Birreg, Juergen (Agfa Germany(GER): Subject: Agfa Prepress & Printing
product query, Pers. e-mail, 17. Oct. 2002.
Cahners Research and the Cahners Printing, Converting, & Creative Group
(Issuer): E-Commerce Exchange, A special report on e-commerce and
the printing industry, No publishing place 2000,
http://www.printcafe.com/corporate/resources/whitepapers/pdf/cahners_ec
ommerce_exchange.pdf [05. Mar. 2003].
Cap Ventures Inc. (Issuer): Print e-Procurement: Changing the Face of the
Printing Industry, Norwell (US) 2000, http://www.capv.com/eprise/main/
Home/Multiclient/Brochures/eprocurpros.pdf [16. Oct. 2002].
Cap Ventures Inc. (Issuer), Michael Maziarka: Assembling the Content Foundation for e-Business Strategies, Xplor Superior Chapter, Norwell (US)
2001, http://www.capv.com/eprise/main/home/Presentations/XPLOR.pdf
[18. Feb. 2003].
Cap Ventures Inc. (Issuer), Pesko, Charles A.: Content on Demand, Reinventing the Printing & Publishing Industry, Norwell (US) 2002,
http://www.capv.com/eprise/main/home/Presentations/CAPKeynote.pdf
[14. Oct. 2002].
© 2003 by Catherine Dammann.
Bibliography
98
Cap Ventures Inc. (Issuer): PoD Overview, Norwell (US) 2002,
http://www.capv.com/eprise/main/Content/Conferences/OD2002/
od2002.html [log in] [05. Mar. 2003].
CIP3 (Issuer): CIP3 Print Production Format (PPF), – workflow doesn´t stop
at prepress!, Darmstadt (GER) 1997, http://www.cip4.org/documents/
ppf_overview/cip3_brochure_e.pdf [05. Mar. 2003].
CIP3 (Issuer): Specification of the CIP3 Print Production Format, Version
3.0, Darmstadt (GER) 1998, http://www.cip4.org/documents/
technical_info/cip3v3_0.pdf [05. Mar. 2003].
CIP4 (Issuer): Job Definition Format (JDF), An Open, Multi-Vendor Solution,
No publishing place 2000, http://www.cip4.org/documents/
jdf_overview/jdf_wp.pdf [05. Mar. 2003].
CIP4 (Issuer): JDF Specification, Release 1.1, Revision A, No publishing place
2002, http://www.cip4.org/documents/jdf_specifications/JDF1.1a.pdf [05.
Mar. 2003].
CIP4 (Issuer): XML Schema for JDF, Version 1.1, Revision A, No publishing
place 2002, http://www.cip4.org/Schema/JDFSchema_1_1/JDF.xsd [20.
Mar. 2003].
Creo Inc. (Issuer): JDF: Standard Interconnectivity in a Creo Networked
Graphic Production Environment, About JDF: Job Definition Format,
No publishing place 2002, http://www.creo.com/documents/
JDF%20Job%20Definition%20Format.pdf [20. Mar. 2003].
European Print Management Association (Issuer): Storyboard for processoriented data exchange with “Management Information Systems” from the
perspective of a fully-networked printing plant, Part 2, Version 1.0, Hanau
(GER) 2002.
Godwin, Robert: Digital Printing: The New Paradigm?, in: Print Buyer Today,
Kingston (US), Vol.2, No. 4 (2002), P. 9, http://www.printbuyertoday.com/
newsite/issues/0402/issue.pdf [16. Oct. 2002].
Harvey, James E.: JDF: Where to Begin, Maryland (US) 2002,
http://www.media4theworld.com/Papers/JDF_where_to_begin.pdf
[04. Nov. 2002].
Hearnden, Jon in: ET Heron is first UK printer to use Delano software, Cox,
Barney, Printweek, London (United Kingdom (UK)) 2002,
http://www.printweek.com/news_story.cfm?ID=11730 [01. Nov. 2002].
Heidelberger Druckmaschinen AG (Issuer), Dr. Rainer Prosi: JDF Technical
Overview, Job Definition Format, No publishing place 2000,
http://www.cip4.org/documents/jdf_overview/
JDFTechnicalOverviewSeybold.pdf [20. Mar. 2003].
INI-GraphicsNet Foundation (Issuer): Electronic Commerce, …ongoing R&D
Activities and Applications, Darmstadt (GER) 1999,
http://www.inigraphics.net/publications/brochures/ecom_broch/ec.pdf
[16. Oct. 2002].
© 2003 by Catherine Dammann.
Bibliography
99
INI-GraphicsNet Foundation (Issuer): Printing and Publishing, Darmstadt
(GER) 2001, http://www.inigraphics.net/publications/brochures/
p_a_p_broch/p_a_p_en.pdf [04. Oct. 2002].
Institut fuer rationale Unternehmensfuehrung in der Druckindustrie e.V. (Issuer),
Eckhard Boelke: Sind wir alle nur noch computergesteuerte Marionetten? Thesen zur Folge und Auswirkung von e-Procurement, Hanau (GER)
2001, http://www.ird-online.de/schulung/fachtagung-2001/08boelke.pdf
[18. Mar. 2003].
Jaeggi, Stephan: PDF-Workflow, Part 1: Basics, Binningen (Switzerland (CH))
1999, http://www.planetpdf.com/planetpdf/pdfs/Basics.pdf
[05. March 2003].
Jaeggi, Stephan: PDF-Workflow, Part 2: Management, Binningen (CH) 1999,
http://www.planetpdf.com/planetpdf/pdfs/Managmnt.pdf [05. Mar. 2003].
Jeffrey, Noel: E-commerce Evolves, in: Print On Demand, No. 9-10, Melville,
(US) 2000, http://www.podb.com/pages/issues/2000/
1000_tf-ecomm_od.shtml [17. Oct. 2002].
Johnson, Mark: XML for the absolute beginner, A guided tour from HTML to
processing XML with Java, No publishing place and date,
http://www.javaworld.com/javaworld/jw-04-1999/jw-04-xml.html
[11. Nov. 2002].
O’Brien, Gareth in: The State of JDF, Everyone’s Talkin’ About JDF, Printwriter, Cherry Hill (US) 2002,
http://www.printwriter.com/articles/101502_oai.html [01. Nov. 2002].
Printcafe Europe Ltd. (Issuer): PrintCafe Print Management Systems Whitepaper, No publishing place 2000, http://www.printcafe.co.uk/corporate/
resources/whitepapers/pdf/mis_whitepaper.pdf [20. Mar. 2003].
Printcafe Software, Inc. (Issuer): White Paper Print E-procurement, No publishing place 2002, http://www.printcafe.com/corporate/resources/
whitepapers/pdf/Print_Eprocurement_Whitepaper.pdf [20. Mar. 2003].
Printcity (Issuer): Printcity Workflow Innovation Leads the Way, Press Release,
Milton Keynes (UK) 2002, http://www.printcity.de/all/dl/
pressrelease_english_printcity_15.pdf [31. Oct. 2002].
PrintTalk (Issuer): PrintTalk, Version 1.1, No publishing place 2002,
http://www.printtalk.org/implementation1-1.pdf [30. Nov. 2002].
Ray, Erik T.: Learning XML, Creating Self-Describing Data, 1st Edition, O’Reilly
& Associates, Sebastopol (US) 2001.
ScenicSoft (Issuer): UpFront White Paper, Production Planning in Today’s Print
Shop Workflow, Lynnwood (US) 2001,
http://www.scenicsoft.com/UpFront/whitepaper.pdf [04. Oct. 2002].
Schatz, Manfred (Druckerei und Verlag Wilhelm Bing): Subject: AW: Automatisierung im Druckbereich - Diplomarbeit ueber JDF, Pers. e-mail, 26.
Sept. 2002.
© 2003 by Catherine Dammann.
Bibliography
100
Smith, Jeremy: Traditional Printing on the Decline: From The Ashes Emerges
A New Industry, In: eXpert Row on www.whattheythink.com, Issue February 2003, No publishing place 2003, http://members.whattheythink.com/
expertrow/jsmith12.cfm [log in] [14. Feb. 2003].
Thimm, The Highpack Company (Issuer): Praxisbeispiel Workflow und Prozessoptimierung in einem Display –Unternehmen, Hanau (GER) 2000,
http://www.ird-online.de/schulung/forum-2000/faltschachtel.pdf
[04. Oct. 2002].
TripleArc (Issuer): A Guide to JDF, London (UK) 2002,
http://www.digitaladlab.com/uk/minutes/jdf-guide.pdf [31. Mar. 2003].
TripleArc (Issuer): Job Messaging Format, e-Bulletin Technology, Issue 1,
London (UK) 2002, http://www.triplearc.com [Request form in library section, 05. Mar. 2003].
Webb, Dr. Joseph W.: Ten Undeniable Trends affecting the printing industry,
in: print e-business report, the monthly newsletter for e-business and ecommerce for the printing industries, Alexandria (US), Vol. October 2001,
http://www.gain.org/PIA_GATF/PDF/1001ebizrpt.pdf [28. Mar. 2003].
WhatTheyThink.com (Issuer): Printers Spending on Web infrastructure in 2002
and 2003: Is Integration Important, In: Confidence Indexes & Research
with CAP Ventures, No publishing place 2002,
http://members.whattheythink.com/surveys/research121102.cfm [log in]
[18. Mar. 2003].
Workflow Management Coalition (Issuer): Workflow and Internet: Catalysts for
Radical Change, A WfMC White Paper, Winchester (UK) 1998,
http://www.wfmc.org/standards/docs/
Workflow_Internet_catalysts_for_change.pdf [04. Oct. 2002].
Workflow Management Coalition (Issuer): Workflow Management Coalition
Specification, Terminology & Glossary, Issue 3.0, Hampshire (UK) 1999,
http://www.wfmc.org/standards/docs/TC-1011_term_glossary_v3.pdf
[04. Oct. 2002].
World Wide Web Consortium (Issuer): Namespaces in XML, No publishing
place 1999, http://www.w3.org/TR/REC-xml-names/ [11. Nov. 2002]
© 2003 by Catherine Dammann.