The CIP4 JDF Editor, The Editing Part: Annaa@kth - Se

The CIP4 JDF Editor, the
Editing Part
- The Development of a CIP4 JDF Editor, Focusing on the

Editing Part Combined with an Investigation of the
Development of JDF
CIP4 JDF Editor,

redigeringsdelen
- Utvecklingen av en CIP4 JDF Editor med fokus på
redigeringsfunktionerna, kombinerad med en undersökning
över utvecklingen av JDF
By
Anna Andersson
Email: annaa@kth.se
Date: 2003-06-16
Subject: Publishing Technology
Supervisors:
Björn Hedin, Graphical art and Media production, the Royal
Institute of Technology
Dr. Rainer Prosi, CIP4/Heidelberger Druckmaschinen AG
Examiner: Prof. Nils Enlund

Sammanfattning
JDF, Job Definition Format, är en ny föreslagen standard för den grafiska industrin, som
gör det möjligt att definiera hela tryckprocessen från tanke till leverans. JDF gör det också
möjligt för produkter från olika leverantörer att kommunicera med varandra. Arbetet med
att ta fram formatet drivs av den internationella organisationen CIP4, the International
Cooperation for Integration in Prepress, Press and Postpress. Den här examensrapporten
beskriver konstruktionen av ”the CIP4 JDF Editor” som är en applikation för att visualisera,
modifiera och validera JDF filer med fokus på framtagandet av de modifierande
funktionerna och hur de samarbetar med den visualiserande delen av applikationen.
Applikationens funktioner definierades tillsammans med experter på Heidelberg

Druckmaschinen AG, där projektet gjordes, och experter inom CIP4’as arbetsgrupp Tools &
Infrastructure. Applikationen är skriven i Java för att möta kravet från CIP4 på en
plattformsoberoende applikation. Den färdiga versionen av ”the CIP4 JDF Editor” stödjer
följande modifikations funktioner:
• Lägga till element/resurser/länkar/attribut

• Döpa om element/attribut
• Klippa/kopiera/klistra
• Ta bort element/attribut
• Spara ändringar
• Skapa ny JDF/JMF fil
I examensarbetet ingår även att göra en matris över produkter som stöder JDF. Matrisen
ska bland annat visa vilka processer och resurser som varje produkt stöder. Denna ska
ligga till grund för att dra slutsatser om hur långt arbetet med JDF har kommit samt även
fungera som underlag för CIP4 då produkter från olika leverantörer ska testas mot
varandra. Bara företag som är ”full members” av CIP4, vilka var 71 stycken i februari
2003, kontaktades för information om eventuella produkter. Av dessa 71 företag kunde
matrisen fyllas i med 32 produkter, vilket är ett relativt dåligt resultat. Anledning till det
dåliga resultatet beror bland annat på att det var för tidigt för somliga företag att ge ut
information om produkter, för att de inte var klara eller för att de inte existerade. En
annan anledning är att företag inte vill lämna ut information om deras produkter för att de
är rädda för konkurrens och en tredje anledning som företagen gav för att inte bidraga
med information var tidsbrist.
För att komplettera matrisen gjordes intervjuer med experter inom CIP4 som är väl
engagerade i utvecklingen av JDF. Från dess intervjuer kunde slutsatser om problem och
status av standarden dras. Det största problemet med JDF är att dess specifikation är så
komplex och därför blir svårförstålig. En ny version av specifikationen ska släppas det
tredje kvartalet 2003 och det är arbetet med denna som arbetet är fokuserat på när
examensarbetet slutförs, maj 2003. Ett annat fokus som leverantörerna har är Drupa
2004, där alla vill kunna visa upp produkter som stödjer JDF.
Abstract
JDF, Job Definition Format, is a new proposed standard for the printing industry that will
enable the whole printing process to be defined and products from different vendors to
collaborate. The development of the proposed standard is controlled by the organization
CIP4, the International Cooperation for Integration in Prepress, Press and Postpress. This
master’s project will describe the construction of an editor that visualize, edits and
validates the JDF, called the CIP4 JDF Editor, with focus on the editing part and how it
interacts with the visualization part of the user interface.
The features of the CIP4 JDF Editor were defined together with experts within Heidelberg
Druckmaschinen AG, where the project was being done, and experts within CIP4. One of
the demands from CIP4 was that the CIP4 JDF Editor should be a platform independent
tool and therefore the application is written in Java. The resulted CIP4 JDF Editor supports
the following editing features:
• Insert elements/resources/links/attributes
• Rename elements/attributes
• Cut, copy, paste
• Delete elements/attributes
• Save changes
• Create new JDF/JMF files
The master’s project also includes the creation of an interoperability matrix, in order to
give an opinion of how far the development of JDF has come today. A from, where JDF
supported products should be filled in, was sent out to all full member companies of CIP4,
which were 71 at the time (February 2003). The information from the interoperability
matrix is complemented with interviews of people involved with the development of JDF
within CIP4. The interoperability matrix was also be used for matchmaking by CIP4, in
order to find possible test partners for interoperability test events between products from
different vendors.
The interoperability matrix resulted in a matrix over 32 JDF supported products, which
shows a fairly small participant from the vendor companies. The small participation were
mainly due to that the vendors did not yet have any information to contribute as they did
not have any finished product that supported JDF. Another reason was that they vendors
did not want to contribute information because of the competition among the vendors;
also the lack of time was a big factor for not participating.
From the interviews problems as well as the status of the development of JDF today could
be drawn. One problem with the specification is very complex and comprehensive though,
this is the main problem of JDF. The complexity makes it necessary for CIP4 to publish
cookbooks to help vendors start implementations. JDF has not been so widely used in
practice so there are not many experiences from end-users yet. A new version, version
1.2, of the specification is to be released in the third quarter of 2003; this is where the
main focus is at the present. New features in version 1.2 are; Capabilities, so devices know
what they are capable of, Preflight, ICS, for better structure and a transport layer to move
JDF around using SOAP. Drupa 2004 is also in focus for the vendors, as everyone wants to
have JDF supported products to show.
Preface
This report is a master project at Media technology, Nada, at the Royal Institute of
Technology in Stockholm. The assigner of the project is CIP4 and it has been performed in
close collaboration with Evelina Thunell. For a full understanding of the project it is
recommended to read “CIP4 JDF Editor – Visualization of JDF” by Evelina Thunell. The
supervisor at the Royal Institute of Technology is Björn Hedin and the supervisor at CIP4 is
Dr. Rainer Prosi. The examiner is Prof. Nils Enlund.
I would like to thank Evelina Thunell for good cooperation, Dr Rainer Prosi for guidance,
support and taking the time to supervise us, Kai Mattern, Dagmar Sclenz and Dietrich
Mucha for advices and help during the project, Koen Van de Poel, Graham Mann, Tom
Hastings and Dr. Meino Spreckelsen for feedback and advices, Charles Qumit, Frank
Theede and Stefan Daun for information and Björn Hedin for support and feedback.
List of Content
1 Background ................................................................................. 1
1.1 JDF .............................................................................................. 1
1.1.1 JDF’s Most Prominent Features.................................................... 1
1.1.2 The structure of JDF .................................................................... 2
1.1.3 Product Intent ............................................................................. 3
1.1.4 JDF Extensibility .......................................................................... 3
1.2 JMF .............................................................................................. 3
1.3 CIP4 ............................................................................................ 3
2 Problem ....................................................................................... 4
3 Purpose ....................................................................................... 5
4 Delimitation ................................................................................. 6
5 Method ........................................................................................ 7
6 Results ........................................................................................ 8
6.1 The CIP4 JDF Editor ..................................................................... 8
6.1.1 An Overview of the Graphical User Interface ............................... 9
6.1.1.1 The Tree View ................................................................................ 9
6.1.1.2 The In- & Output View..................................................................... 9
6.1.1.3 The Process View.......................................................................... 10
6.1.1.4 The Error View ............................................................................. 11
6.1.1.5 The Attribute View ........................................................................ 11
6.1.2 The Editor Part .......................................................................... 11
6.1.2.1 Synchronization between the JDF Document and the Tree Structure ... 12
6.1.2.2 Adding and Modifying Elements ...................................................... 13
6.1.2.2.1 Renaming Elements ...................................................................... 13
6.1.2.3 Adding and Modifying Attributes ..................................................... 14
6.1.2.4 Adding Resources ......................................................................... 14
6.1.2.5 Adding Links ................................................................................ 15
6.1.2.6 Create New JDF/JMF Files .............................................................. 15
6.1.2.7 Cut, Copy, Paste and Delete........................................................... 15
6.1.2.8 Save and Save As ......................................................................... 16
6.1.3 How the Connection between Editing and Validation of the
JDF Has Been Solved............................................................... 16
6.1.4 What does the CIP4 JDF Editor not handle?............................... 17
6.1.4.1 Support for Foreign Namespaces .................................................... 17
6.1.4.2 Check how Many Elements of the Same Kind that are Valid to Add………17
6.1.4.3 Provide Value Suggestions for Every Kinds of Attributes when they
are being changed ........................................................................ 17
6.1.4.4 Support Required Elements to be added .......................................... 18
6.1.5 Bugs and Errors ......................................................................... 18
6.2 Study Over the Use of the CIP4 JDF Editor in a Multi-Vendor
Environment .............................................................................. 18
6.2.1 Who Could Use the CIP4 JDF Editor and For What? ................... 18
6.2.2 Where does job Tickets Get Created and When is Validation
and Editing Necessary during the Printing Process? .................. 19
6.2.3 The job Tickets Way, from Idea to Printed Product.................... 19
6.3 The Interoperability Matrix........................................................ 21
6.3.1 The Support for JDF Features .................................................... 22
6.3.2 The Support for Intents and Processes...................................... 22
6.3.3 The Support for JDF Process Resources ..................................... 22
6.3.4 The Support for JMF................................................................... 22
6.3.5 The Lack of Time within CIP4 .................................................... 23
6.4 The Evolution of JDF .................................................................. 23
6.4.1 The Need for JDF ....................................................................... 23
6.4.1.1 The Vendors Need for JDF.............................................................. 23
6.4.1.2 The Customers Need for JDF .......................................................... 23
6.4.2 Status of the JDF Development Today ....................................... 24
6.4.2.1 Preflight ...................................................................................... 24
6.4.2.2 The Newspaper Industry................................................................ 24
6.4.2.3 Version 1.2 of the Standard ........................................................... 24
6.4.2.4 The Market .................................................................................. 25
6.4.3 Focus ......................................................................................... 25
6.4.3.1 Which Kinds of Companies are Likely to Start Using JDF as a
Standard?.................................................................................... 25
6.4.4 Time Perspective ....................................................................... 25
6.4.4.1 Drupa 2004 ................................................................................. 25
6.4.4.2 Drupa 2008 ................................................................................. 26
6.4.5 Problems with the Development of JDF ..................................... 26
6.4.5.1 The Newspaper Industry................................................................ 26
6.4.5.2 The Complexity – Is JDF Too Complex To Be Handled? ...................... 26
6.4.5.3 The Multi-Vendor Development....................................................... 26
6.4.5.4 Flexibility – Multi Dialects/Extensions .............................................. 27
6.4.5.5 Lack of MIS Companies Involved .................................................... 27
7 Conclusions/Discussion ............................................................. 28
7.1 Conclusions from the Interoperability Matrix ............................ 28
7.2 Discussion over the Resulting CIP4 JDF Editor .......................... 28
7.2.1 Conclusions over the Usefulness of the CIP4 JDF Editor ............ 28
8 Recommendations ..................................................................... 30
9 Reference: ................................................................................. 31
9.1 Interviews ................................................................................. 31
9.2 Literature .................................................................................. 31
9.3 Electronically References:.......................................................... 31
Appendix 1: The Interoperability Matrix..................................................... 32
Appendix 2: Glossary.................................................................................. 40
Master Project Anna Andersson 16/06/2003
1 Background
This chapter describes JDF, Job Definition Format, and CIP4, the International Cooperation
for Integration in Prepress, Press and Postpress, which is the organization that develops
JDF. The most important features about JDF have been described so that the reader will be
able to understand the concept and terminology in the following chapters.
1.1 JDF
JDF stands for Job Definition Format and is a comprehensive XML-based file; see figure 1,
and a proposed industry standard for end-to-end job ticket specifications combined with a
message description standard and message interchange protocol. JDF is designed to
streamline information exchange between different applications and systems. JDF is
intended to enable the entire industry, including media, design, and graphic arts, on
demand and e-commerce companies to implement and work with individual workflow
solutions. JDF will allow integration of heterogeneous products from diverse vendors to
seamless workflow solutions [6].
JDF is based on the idea to develop an open, extensible, XML-based job ticket standard, 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. Building on existing technologies of CIP3's PPF and Adobe's PJTF, the Job
Definition Format supplies a means for printing businesses to streamline the process of
producing printed material [6].
<?xml version="1.0" encoding="UTF-8" ?>

<JDF ID="n20030406150412" Status="Waiting" Type="Product" Version="1_1"
xmlns="http://www.CIP4.org/JDFSchema_1_1">

<AuditPool>
<Created Author="JDFLib-J JDFWriter 27.2.2002" TimeStamp="2003-04-
06T13:04:12+00:00" />
</AuditPool>
<ResourcePool>
<ColorIntent Class="Intent" ID="465979000025" Locked="false"
Status="Unavailable" />
<DeliveryIntent Class="Intent" ID="Link403028000058" Locked="false"
Status="Unavailable" />
</ResourcePool>
<ResourceLinkPool>
<DeliveryIntentLink Usage="Input" rRef="Link403028000058" />
<ColorIntentLink Usage="Input" rRef="465979000025" />
</ResourceLinkPool>
</JDF>
Figure 1, a short example of a JDF file with an AuditPool, resources and resource links.
1.1.1 JDF’s Most Prominent Features
The most prominent features about JDF are as follows:

• Ability to carry a print job from genesis through completion. This includes a
detailed description of the creative, prepress, press, post press and delivery
processes.
• Ability to bridge the communication gap between production and Management
Information Services. This ability enables instantaneous job and device tracking
as well as detailed pre- and post calculation of jobs in the graphic arts.
1
• Ability to bridge the gap between the customer's view of product and the
manufacturing process by defining a process independent product view as well as
a process dependent production view of a print job.
• Ability to define and track any user defined workflow without constraints on the
supported workflow models. This includes serial, parallel, overlapping and
iterative processing in arbitrary combinations and over distributed locations.
• Ability to do the described points above under nearly any precondition.
1.1.2 The structure of JDF
The whole JDF project is called a job, which is ordered in a tree structure and contains all
required information necessary to complete the project, see figure 1. The information is
stored in different nodes in the tree which all represents a specific part of the job.
Common nodes are Product Intent Nodes, Process Group Nodes, Combined Process Nodes
and Process Nodes. The nodes contain subparts called elements. An Element is an XML
syntactic construct and can be subparts of other elements and is then referred to as sub
elements. Nodes are also XML elements but they are used in the JDF Specification to make
a distinction between the independent JDF characteristic and its subparts. Examples of
elements are the AuditPool, which contains post-facto recorded results of a process, the
Customer Info element that stores information about the customer who ordered the job,
the Node Information element to store information about planned scheduling and message
routing and to make planning possible and finally there are Resource elements and
Resource Links element. The Resource Links element is an important component in JDF,
which can be of internal or external character. Internal links points to information located
within the JDF file and referenced data is stored in a target element, called the Resource
element, see figure 1. There can be several links pointing at the same Resource element
but the Resource elements are unique and can only exist once inside the JDF document.
This means that a resource can be produced by one or more nodes and also consumed by
one or more nodes see figure 2.
Output Link 1
Node1 Input Link 3
Resource Node 3
Node2
Output Link 2
Figure 2, three different nodes using the same resources either as an input resource or as
an output resource; the resource is located by using resource links.
External links are using standard URL’s and refer to a target outside the JDF file, such as
content files or color profile. The different characteristics of the elements are represented
by their attributes, which also are an XML syntactic construct. An example of an attribute
is the ID attribute, which is a unique identifier of each node [6]. Resources and JDF
elements have the ID attributes as required attributes; the attribute for the identification
of resource link elements is the rRef attribute. Letting the rRef attribute value have the
same value as the ID attributes for the resource creates the connection between the
resource and its link. The JDF node is connected to the resource by having the resource
link element as a child element.
2
1.1.3 Product Intent
The product intent is the specifications of a print job; it describes what a job will look like
when it is done. The product intent is only a plan of action, which can be very vague and
only specify the general goal for the product, or it can be very specific and specifying
requirements inherent in meeting that goal [6].
1.1.4 JDF Extensibility
The significance of JDF is that it should be flexible and therefore useful to any vendor as
each vendor has specific data to include in the JDF files. Every vendor should be able to
add its own XML elements, attributes and enumerations to their application. JDF provides
this extensibility with XML namespaces. The extensibility is meant to provide both printers
and technology providers with the flexibility they need to make JDF a success [6].
1.2 JMF
JMF, Job Messaging Format, is JDF-based and provides a wide range of capabilities to
smooth the progress of interaction between the various aspects of a workflow. JMF works
as an interface between the production equipment and the Management Information
Systems (MIS). The power of JMF is described with the following example in the JDF
specification 1.0: “In order to automate aspects of your production without JDF, your
technical staff must become proficient in each of the command languages that each of
your devices employ. By only buying JDF-enabled devices that use JMF as their control
language, you only have to learn one new device command language… eventually, the only
your MIS staff will need” [6].
1.3 CIP4
CIP4 stands for International Cooperation for the Integration of Processes in Prepress,
Press and Post press and is an international, worldwide operating standards body located
in Switzerland. The purpose of the association is to encourage computer based integration
of all processes that have to be considered in the graphic arts industry, in particular the
specification of standards. CIP4 is about to develop and promote vendor independent
standards for the graphic arts industry, such as the new Job Definition Format, JDF. CIP4
runs several working groups in order to develop new extensions of JDF and to discuss
future use cases [7]. Currently, May 2003, CIP4 is running the following working groups
[7]:
• Advertising / Magazine publishing
• Capabilities
• Color Workflow
• Device messaging / Job tracking
• Digital Printing
• eCommerce
• Finishing
• Gravure
• Newspaper
• Origination and Prepress
• Packaging & Label
• Process resources and definitions
• System Behavior and Interoperability
• Tools & Infrastructure
• User Group
• Web/Rotary printing
3
2 Problem
The difference between JDF and XML is that JDF contains resources and resource links.
This means that the resources and the resource links cannot be visualized or modified by
using an ordinary XML editor. Today there is no editor that validates, visualizes and views
JDF files together with its resources and links, and the need for it is apparent. Most JDF
users use the Internet Explorer, which only displays the source code, as a tool for viewing
the files. This makes it hard to get a clear overview of the files. Processes and resources
are not viewed in an efficient way and editing and validation of the files is complicated,
since the only way to edit the files is to write the code in a text editor and that means that
spelling errors and mistakes, like new elements/resources/resource links, inserted in the
wrong positions, are easily done. The task of this master project is to develop a tool, called
the CIP4 JDF Editor, which handles the described features above. How can such a tool be
developed and how will the editor part interact with the visualization part of the user
interface?
Focus will be on the development of the editor part and an investigation will be done over
the use of the CIP4 JDF Editor. Following issues regarding the development of the CIP4
JDF Editor will be described:
• An Overview of the Graphical User Interface
• The Editor Part
• How the Connection Between Editing and Validation of the JDF has been solved
• What is Not Handled by the CIP4 JDF Editor
• Bugs & Errors
• Who Could Use the CIP4 JDF Editor and For What?
• Where Does job Tickets Get Created and When is Validation and Editing
Necessary during the Printing Process?
Given that JDF is a new format, this thesis will also cover an investigation of the
development of JDF together with a construction of an interoperability matrix on behalf of
CIP4 and the interoperability working group. The interoperability matrix will contain
information over JDF supported products and which kind of processes and resources they
produce and consume. The matrix will then work as a base for testing the interoperability
between products from different vendors. The interoperability matrix together with
interviews with people involved in the development of JDF will also be used for the
investigation over the development of JDF. The following issues will be discussed:
• The need for JDF
• Status of the JDF development today
• Focus
• Time perspective
• Problems with the development of JDF
4
3 Purpose
The purpose of developing the CIP4 JDF Editor is to create a user interface that is easy to
use and that clearly views the JDF files, their processes and resources and the connection
between them. The CIP4 JDF editor will also be a tool for editing and validation of JDF
files. The editor part of the user interface will enable that modifications of the JDF will be
done in a more user friendly way. Since there is no such a tool on the market today the
need for such a tool is prominent for the development of JDF. The CIP4 JDF Editor will also
view and edit JMF files.
The investigation over the development of JDF will be done to provide a good overview of
the status of the format. The work with putting together the interoperability matrix is done
to collect information about the different products supporting JDF and store them in one
place. This will make a good overview over the market and very easy to compare different
products with each other. The interoperability matrix will show supported processes and
resources by the products and will serve as a good base when products are about to be
tested with each other. It will also give an indication of how widely spread JDF is among
the vendors and conclusions about how far the development of JDF has come.
5
4 Delimitation
Due to the time limit for this master project following JDF features are not supported by
the CIP4 JDF Editor:
• Schema validation
• Ref elements
• Partition display
The general features that are left out are; drag and drop, undo, redo, a source view,
printing and the ability to hide and show the attributes in the tree view.
We have delimited the investigation of JDF-supported products among the vendors who
are CIP4 members and only contacted full member vendors. It is important to mention
that the interoperability matrix does not give a complete overview of the market, because
it is likely that a lot of products are under development and the companies do not want to
contribute information about them yet.
6
5 Method
Since the author was not familiar with the JDF format the approach was to start reading
the JDF Specification 1.1 [6]. Regarding the development of the CIP4 JDF Editor the first
step was to have a meeting with the CIP4 and people specialized in creating user
interfaces at Heidelberger Druckmaschinen AG, in order to get a feeling for how the CIP4
JDF Editor would look like and how the work would be done. Next step was to analyze
different XML editors on the market and look at the different user interfaces and their
features. The result from this investigation together with the requirements from CIP4
served as a base to decide how the CIP4 JDF Editor should look like and what kind of
features it would include. The coding was done in Java so the CIP4 JDF Editor could meet
the requirement of a platform independent tool from CIP4. Eclipse 2.0 was used as
development environment as that is the development environment used at Heidelberg
Druckmaschinen AG. The source is partly based on the CIP4 Java JDF Library, developed
by Heidelberger Druckmaschinen AG. Due to the big size and complexity of the CIP4 Java
JDF Library a study over it had to be done before it could be used. An open discussion was
constantly held between the developers of the CIP4 JDF Editor and the developers of the
Java JDF Library so that it could meet the requirements of the CIP4 JDF Editor. JProfiler
was used as a tool to discover and solve performance problems with the application.
The coding was done partly separately and partly together with Evelina Thunell on
different computers and the code was frequently merged into one core project using
Clearcase. Though the development was partly done separately between the two
developers there were constantly a very close collaboration for decision making and
problem solving. The development was also done in close cooperation with experts at the
CIP4 Tools and Infrastructure working group. The progress was monthly presented at their
teleconferences for feedback and update. Problems that aroused during the development
were solved collaboratively with experts within CIP4 and Heidelberg Druckmaschinen AG.
During the time of the development of the CIP4 JDF Editor, two versions of it were
released at the CIP4 web site, so that the members could try the application at an early
stage and see if the progress was made in the right direction. The CIP4 JDF Editor has also
been tested by JDF developers at Heidelberg Druckmaschinen AG during the process of the
development. Their opinions and suggestions of how to improve the application were used
in the development.
Regarding the creating of the interoperability matrix, the first step was to create a form
with information about JDF supportive products, and the processes and resources they
consume or produce, to be filled in. Next step was finding the contact person at every full
member company of CIP4 and then contact them and ask them if they could contribute
information to the interoperability matrix and then finally the information was put
together. The information was then analyzed and used in the investigation of the
development of JDF. To get more information about the development of JDF interviews of
chairmen in some of the working groups within CIP4 was done.
7
6 Results
The result from this master project has been divided into four chapters, which are “The
CIP4 JDF Editor” where the resulted features of the application is presented, “Study over
the Use of the CIP4 JDF Editor in a Multi-Vendor Environment” which is describing the
usefulness of the application, “The Interoperability Matrix” where the resulted
Interoperability Matrix is being described together with conclusions over the development
of JDF that could be drawn from it. The last chapter is “The Evolution of JDF”, which is a
description over the development of JDF.
6.1 The CIP4 JDF Editor
The validating CIP4 JDF Editor is a tool for visualization and modification of JDF files. The
user interface was built by using Java Swing components. It reads and opens a JDF file or
JMF file and displays the file as a tree, with different icons depending on if the node in the
tree is representing an element or an attribute and if the node is valid or not. The CIP4
JDF Editor also shows the relationship between the different nodes in the tree in different
ways. The CIP4 JDF Editor contains of five different views that are displaying different
information about the JDF file. The views are:
• The Tree View
• The In- & Output View
• The Process View
• The Error View
• The Attribute View
The views are shortly described under chapter 6.1.1 “An Overview of the Graphical User
Interface”.
JDF files can be validated with the CIP4 JDF Editor. This can be done when the file is
opened or after editing, either automatically or on demand from the user. Editing of JDF
files is only supported for elements and attributes that not belong to a foreign namespace.
The supported editing features are:
• Insert elements/resources/links/attributes
• Rename elements/attributes
• Cut, copy, paste
• Delete elements/attributes
• Save changes
These features will be described in detailed under chapter 6.1.2 “The Editor Part”.
8
Figure 3, the CIP4 JDF Editor, with the Tree View, In- & Output View and the Error View
activated.
Besides viewing, editing and validation of JDF files the CIP4 JDF Editor also contains other
features like open recent file, changeable “Look & Feel”, changeable language for the
application where it is possible to choose between English, French, German, Spanish and
Swedish, a search function, a help function and it is also possible to choose “open with” in
the explorer and choose to open the file with the CIP4 JDF Editor.
6.1.1 An Overview of the Graphical User Interface
This chapter will shortly describe the different views in the CIP4 JDF Editor so the reader
will be able to understand the concepts mentioned when the Editor part is being described.
For more information about how the graphical user interface was developed please read
Evelina Thunell’s report.
6.1.1.1 The Tree View
The Tree View, see figure 3, is the main view of the application and it displays the file as a
tree. All elements have folder icons and the attributes have document icons. If the element
or attribute is invalid, this will be showed by a red error icon and if the element or attribute
belongs to a foreign namespace this will be marked by displaying the describing text of the
tree node in blue instead for its original color which is black.
6.1.1.2 The In- & Output View
The In- & output view is displaying the connection between the JDF nodes and the
resources in the JDF file. If a JDF node is selected in the tree view the In- & Output View
displays the JDF node centered with its input –and output resources to the left respectively
9
to the right, see figure 3, or if a resource is selected it displays a resource centered

together with its JDF producer and consumer, see figure 4, which are also to the left
respectively to the right. Three headers are always shown in this view over the nodes and
the resources. The headers can have the following text; “Input Resource”, “JDF Node”,
“Output Resource”, “JDF Producer”, “Resource” and finally “JDF Consumer”. The looks of
the JDF nodes and the resources are displayed with the same style and folder and attribute
icons, as they are displayed in the tree view. If a node or attribute is invalid this is also
shown with the same invalid icon as in the tree view.
Figure 4, the In- & Output View showing a resource together with its JDF producer and
consumer.
A JDF node and resource is only displayed with its attributes, which means that the
children to the displayed node are not viewed. Resources with inherited attributes are
displayed with both its own attributes and its inherited attributes. We have chosen to
visually distinguish between the inherited attributes and the other attributes by displaying
them with a bold text. JDF nodes and resources that belong to a foreign namespace are
not showed in this view.
6.1.1.3 The Process View
The Process View, which is shown in figure 5, displays the whole process for a selected JDF
node in the Tree View. The Process View displays the node and its resources and also the
children to the node together with its resources are displayed. This view shows the
relations between the different children, who is producing the resources and who is
consuming them. A click with the mouse on one of the children will display the process
view for that node. Only JDF nodes and resources are displayed in the Process View. Lines
between the resources and the JDF nodes show which JDF nodes that consume which
resources and which who produce them. Consumed resources by a JDF node is placed to
the left of it and produced resources to the right.
10
Figure 5, the Process View showing the relations between resources and processes
6.1.1.4 The Error View
The Error View, see figure 3, displays a list of the errors of selected node in the Tree View.
It displays the error for that node and its invalid children if it has any.
6.1.1.5 The Attribute View
The Attribute View is a simple text view displaying the attributes for the selected node in
the tree view. The attribute view only displays attributes for the JDF elements and the
resources; if any other kind of node is selected in the tree the attribute view will be empty.
6.1.2 The Editor Part
A JDF file can be opened with the editing features turned either on or off. In the latter case
the JDF file will be opened as a read only file and the CIP4 JDF Editor will then work
exclusively as a viewer and the file is secured from being modified by accident. When a
JDF file is opened with editing turned on, which is the default state for this function; it is
ready to be modified. The editing mode can only be changed before the JDF file is opened,
so if the mode is wished to be changed the JDF file has to be closed. This is done for safety
reasons to prevent a read only file from being available for editing during the same
session. The editing mode is changed under “Edit On/Off” in the “Edit” menu.
Editing is only available in the Tree View and the editing operations can be reached from
the main menu under “Edit” and from the right mouse menu, see figure 6. Some editing
functions are also represented with quick buttons in the toolbar, see figure 3, and also by
short commands from the keyboard. Only those editing alternatives that are possible for
the object that are to be modified are accessible in the menus and the toolbar. The
selected node in the Tree View is the node that is being modified, so in following chapters
when the node is mentioned it is referred to the selected node in the Tree View. The CIP4
JDF Editor supports the following editing functions:
• Add new element
• Add new attribute
• Add new resource
• Add new resource link
• Add required attributes
• Copy, cut, paste
• Delete
11
• Rename
• Save/Save As
Methods for editing functions like finding the right element as well as insert and delete
elements in the JDF document were mainly solved by using the Java JDF Library.
All the different views in the CIP4 JDF Editor are updated synchronically with the editing,
except for the Error View, which is only updated if the validation is turned on.
Figure 6, the right mouse menu
6.1.2.1 Synchronization between the JDF Document and the Tree Structure
The JDF document and the tree in the Tree View are only connected through the Tree
Node, which is a customized tree node that stores the JDF element it is representing. This
means that the application have to update the JDF document and the tree structure
simultaneously, only a visual update is not enough. Updates in the tree structure are
mainly done with methods from the JTtree class in Java and the Java JDF Library is used
for updates and modifications in the JDF document.
In the Java JDF Library there are methods for modifying the elements and adding new or
delete old elements. The procedures are done in a specific way; new elements and
attributes are added in a specific order. This means that the modifications of the JDF
document have to be done at first and then the tree structure can be updated so it
matches and represents the JDF document in a correct manner. The methods in the Java
JDF Library are more precise and developed than they are in the methods that are used for
modifying the tree structure. This combined with that there are no connection between the
JDF document and the tree structure besides the storing of the JDF element in the tree
node complicates the editing.
The biggest problem with adding new attributes is that the tree node does not know which
position the attribute has. The attributes are automatically arranged in an alphabetic order
and it is hard and complicated to find a fast algorithm for the tree structure to solve this.
The solution was to delete the modified node form the tree structure and store the node
and its position and its children if it has any. The same node is then inserted again at the
same position, and the changes are automatically done. When a new tree node is to be
inserted in the tree structure the JDF element that is to be displayed is checked if it has
any attributes and if so a method for adding attributes to the tree node is being used. The
method checks the JDF element for attributes and creates corresponding tree nodes for
each attribute and attaches them to the tree node. The attributes are now represented in
the same alphabetic order as they are in the JDF document. If the tree node contained
children they are attached to the node after the attributes without changes.
12
The most common way to insert a new element is to insert it into another element, if this
is the case the element is added last in the array of children to that element. In this the
synchronization between the tree structure and the JDF document is done easily. But if an
element is to be inserted before or after another element, the position of that reference
tree node is needed, and depending on if the option is to insert the element before or after
the position has to be decreased respectively increased before the new node can be
inserted in the tree structure.
If a node or attribute is renamed the methods in the Java JDF Library are used for
renaming the JDF elements and attributes and after that the corresponding tree node are
deleted and a new one is constructed.
6.1.2.2 Adding and Modifying Elements
New elements can be inserted into, before and after a node, but if the node is the root of
the whole file there is only possible to add a new element into that node. The option for
inserting new elements is found under “Insert Element” in the main menu and the right
mouse menu. When “Insert Element” => “into” is chosen, a list of possible elements to
insert under this node appears and it is easy to choose and insert the requested element.
This obstructs errors like spelling errors and elements at invalid positions in the JDF
document from being created during editing. If “Insert Element” => “Before” or “After” is
chosen a list of possible elements to the parent of the node will appear in the list.
Figure 7, a list of valid elements that can be inserted under a JDF element
To get the list of elements that are valid to insert under a specific node in the tree the Java
JDF Library is used.
When a new element is inserted, the required attributes, if it has any, are inserted as well.
This contributes to that fewer steps are required during editing. [For more info about
inserting attributes see chapter 6.1.2.3 “Adding and Modifying Attributes”]
6.1.2.2.1 Renaming Elements
The only modification that can be done of the element itself besides adding new attributes
or children is to rename it. Renaming elements are only necessary when a spelling mistake
has been done. An example of a spelling mistake is naming an element Auditpul instead of
AuditPool. Renaming of elements is only necessary when there has been a spelling mistake
before the JDF file is loaded into the CIP4 JDF Editor as these kinds of mistakes can not be
done using the CIP4 JDF Editor. The user is prevented from giving the element an invalid
name as the CIP4 JDF Editor lets the user choose from a list of elements that are valid in
that position. This operation is found under “Rename” in the main menu and the right
mouse menu.
13
6.1.2.3 Adding and Modifying Attributes
Inserting new attributes can be done from the “Insert Attributes” option in the main menu
and also in the right mouse menu. The procedure for adding new attribute is similar to the
procedure that is used for adding new elements. A list of valid attributes both required and
optional attributes except already existing attributes are created using the Java JDF
Library. It is also possible to add all required attributes at once, this is done under “Add
Required Attributes” that are available from the main menu and the right mouse menu.
A default value is added to some of the most common attributes as they are created;
otherwise the value is set to be “New Value”. The user can then choose to change the
value of the attribute, this is done under “Change value” in the main menu and from the
right mouse menu but only if an attribute is selected. For some of the attributes there are
predefined values to choose from in the Java JDF Library and the user is able to choose
among them, for others there are no predefined values and then the user has to type in
the value of the attribute. Among the predefined values that are listed there is an “other”
option added at the end of the list so that the user can type in desired value.
6.1.2.4 Adding Resources
A new resource can be added either as an input or as an output resource and with or
without a link. The procedure is the same as when an element is added. The element that
the node is representing is used to create a list of valid resources under the node and it is
displayed to the user to choose from. Finding the valid resources is more complicated than
finding valid elements for a node. The information about that the node contains an JDF
element or for example an AuditPool is not enough, the editor has to know exactly what
kind of JDF element the node contains to pick out valid resources and list them. Every
different JDF element belongs to different classes, which not appear at first. To find out
which class the JDF element belongs to, reflection is used and when the right class is found
a new instance of that class is created and the method for getting the valid resources are
invoked. When the user then chooses a resource, a new resource is created to add to the
node.
Creating a new resource is also more complicated than it is for other elements. First of all
the resource has to be created from an existing element; secondly the resource has to be
created with the class attribute and finally the resource must be created with a valid
resource name. The existing element and the valid resource name are easy to get, as
element the one that belongs to the node is used and the valid resource name comes from
the choice of the user that she/he picks from the list of valid names. It is however
impossible to get the valid class attribute for the resource that are to be created because
that information is only available from an existing resource. This is solved by always
creating all kinds of resources with the class attribute value “Intent”; this is done just to
have a value for that attribute. When the resource is created it is created with a method in
the Java JDF Library that automatically appends it to the element represented by the node.
When this is done we have a new resource, which has a valid resource name but not the
valid class attribute. Finding the initiate method for that specific kind of resource in the
Java JDF Library, when right initiate method is found the resource is initiated and
automatically given the correct class attribute solves this. The right initiate method for the
resource is found by using reflection.
When the new resource is added to the element, it is added to the elements ResourcePool
element. If the element does not contain such an element methods from the Java JDF
Library are constructing a ResourcePool element. Before a new resource can be added to
the element it is necessary to check if the element has a ResourcePool element or if a new
one is going to be created. This information is important for the next step, which is to
update the tree structure so it represents the modified JDF document in an accurate way.
If this information was not stored before the creation of the new resource element the tree
structure would never be updated with a new ResourcePool element because at that
staged in the process the element will always contain such an element. This is done in the
14
same procedure as described in chapter 6.1.2.1 “Synchronization between the JDF

Document and the Tree Structure”.
It is possible to add resources with or without a link. In both cases the same method is
used from the Java JDF Library and there is just a change of a variable telling the method
if it should create a link or not. If a link is to be created as well, it is added under the same
element as the resource element. If the element already contains a ResourceLinkPool
element the link will be added to that one otherwise a new will be constructed
automatically from the method. In this case it is also important to check if the element
contains a ResourceLinkPool element before the link is created for the same reason as for
the ResourcePool element.
If it is chosen to add a resource element without the link the resource element will always
be created as an input resource, this can easily be changed to output when the link has
been added. The operation of adding a resource without a link will create a validation error
with the error message “Unlinked Resource”. It is necessary to have this function as it
enables to add links in different positions than under the same element as the resources
are added to.
The tree different options handled in this chapter are reached from both the main menu
and the right mouse menu under “Insert Resource” => “Input Resource”, “Output
Resource” and finally “Resource”. The last one is the option for adding a resource element
without the link.
6.1.2.5 Adding Links
It is only possible to add links to already existing resources in the JDF document. Adding
new links are done in a similar way as adding resources or elements earlier described in
this report. The user gets a list of possible resources to link. The list of possible resources
is created by searching the tree structure for all existing resource tree nodes in it. When a
resource is selected to be linked the link is created out of that resource. The usage
attribute is set to the same value stored in the resource element and the rRefs attribute is
set to the same value as the ID attribute of the resource element. Adding new links are
possible from the “Insert Resource” => “Resource Link” from both the main and the right
mouse menu.
6.1.2.6 Create New JDF/JMF Files
The CIP4 JDF Editor also supports the creation of new JDF or JMF files. This can be done
from the “File” menu under “New” or with the “New Button” in the toolbar. When this
function is called a question if a JDF or JMF file is to be created is shown to the user.
Methods from the Java JDF Library are used for doing these operations. After the file has
been created it is displayed in the tree view like ordinary files. When closing the created
file a save question will pop up and the user has to choose if and where the file should be
saved.
6.1.2.7 Cut, Copy, Paste and Delete
The functions copy, cut and paste can be reached from quick buttons in the toolbar and
the main respectively the right mouse menu and as a last option from command keys
using the keyboard. Delete is also available from the both menus and the keyboard but not
from the toolbar.
The fist thing that happens when the cut function is being invoked is that the affected tree
node is stored in a global variable. After that the node is removed both from the tree
structure and the JDF document. The variable will now have this value until a new tree
node is being cut or copied and it will be emptied when the file is closed or the paste
function is invoked.
15
The procedure for copying a node is similar to the procedure for cutting a node. The tree
node is first stored in the same global variable, as being used in the cutting process but
the node is not deleted, as it is when it is cut. However if the element represented by the
copied tree node has an ID attribute the attribute value has to be modified before it is
paste into the JDF document. This is necessary due to the fact that the ID attributes are
unique for every element and therefore cannot appear twice within the same JDF
document.
The paste feature works like feature for adding a new element or attribute into another
element. The copied or cut element is being added in the last position under the element is
should belong to. If an attribute is being pasted it is attached in the alphabetic order used
by the Java JDF Library and thereafter the tree node is being repainted. For further
information about the insertion of attributes and update of the tree structure see chapter
6.1.2.1 “Synchronization between the JDF Document and the Tree Structure”.
When an attribute node or element node is deleted from the tree structure the JDF
document is updated as well. It is possible to delete any kind of node in the tree except for
the root node. When an element is being deleted all its children are deleted as well and the
tree structure is withdrawn.
6.1.2.8 Save and Save As
The save function will always be invoked when a file has been modified and the user is
either closing the file or the application. If a new file has been created the user has to
define where and if the new file should be saved. The save function are available from the
“File” menu under “Save” and from the quick button in the toolbar. The file can be saved
several times during editing, and the file is written back to the same location. A file can
also be saved as a new file with the save as function that are available from the “File”
menu under “Save As..” the user now have to choose a new name and location for the file.
A save as function is needed if a user wants to modify a file and keep the original at the
same time.
6.1.3 How the Connection between Editing and Validation of the

JDF Has Been Solved
A file can be opened with or without automatic validation; this is changed under
“Automatic Validation On/Off” in the “Validation” menu. The default value for this function
is to have it turned off; this is done because of the time consumption the validation is
consuming while the JDF file is being opened. Automatic validation can also be very time
consuming during editing of larger files. The size of a JDF file can vary between 100 bytes
up to 300 kilo bytes or more. A file around 300 kilo bytes is considered to be a large file
and it is around this size of a file were the CIP4 JDF Editor is getting slow. Files with a size
between 10 and 30 kilo bytes are the most common ones.
Automatic validation validates every change done in the JDF file immediately and displays
found error in the Error View and with the read error icons on the affected tree node. The
automatic validation is only validating affected nodes and leaves the rest out; this is done
to make the validation faster. But as the files are getting larger the automatic validation is
getting slower and mistakes in the validation can be found. The most time consuming part
of the automatic validation is to search through the “ResourcePool” and “ResourceLinkPool”
elements in the file for unlinked resources or links that are linked to non-existing
resources. The problem with the automatic validation is that there are so many different
cases that have to be covered. Most of the known cases are handled well with the
automatic validation but there are more cases to be discovered and it is not certain that
the automatic validation can handle them.
A more accurate way to validate the file is to have the automatic validation turned off in its
default mode and uses the “Validate Button” in the toolbar for validation of the JDF file.
When the validation is invoked by the “Validate Button” the whole JDF file is then
16
validated. This guaranties an accurate validation result of the file and editing operation is
done faster without validation interruptions. The disadvantage of having the automatic
validation turned off is that it prevents the user from immediately discover if the operation
was valid or not.
Validating a whole file around 300 kilo bytes takes 25 seconds if the automatic validation is
turned on it takes about 14 to 18 seconds to validate a the file when an element is
deleted. The procedure of inserting a new resource takes under 10 seconds to validate.
The delete operation is more time consuming than the insert operation. This is explained
by the fact that after a delete operation a larger search for affected nodes has to be done
in order to find possible unlinked resources or resource links without a resource. Validating
a file around 20 kilo bytes takes under a second to validate, and deleting an element with
the automatic validation turned on takes about 2 seconds, inserting a new resource is
done under a second. This means that it is convenient to have the automatic validation
turned on when smaller files are being modified; the user gets the validation result at once
without any disturbing interruptions. When larger files are being modified it is
recommended to have the automatic validation turned off, as an interruption up to 18
seconds would appear to be a disturbing factor. It would be less time consuming to do
every modifications of the file at once and then validate the whole file.
Validation is founded on algorithms from the existing checkJDF, which is a program that
validates JDF files, developed by CIP4.
6.1.4 What does the CIP4 JDF Editor not handle?
This chapter will discuss some of the editing features that are not handled by the CIP4 JDF
Editor. These features are brought up because they are very close to or should be included
in other editing features supported by the CIP4 JDF Editor. The fact that these are missing
leaves the CIP4 JDF Editor in an “unfinished” state.
6.1.4.1 Support for Foreign Namespaces
The CIP4 JDF Editor does not handle schema validation and this means that elements and
attributes can not be edited by the application; and therefore the application does not
know what kind of element or attribute it is dealing with. Elements and attributes that
belong to a foreign namespace are commonly used and therefore the editor in most cases
is only capable of edit a certain percentage of the JDF file, which makes the user
dissatisfied.
6.1.4.2 Check how Many Elements of the Same Kind that are Valid to Add
The JDF specification only allows a certain number of the same elements to exist under
another element. This is something that neither the CIP4 JDF Editor, nor the Java JDF
Library supports or controls. At the present stage of the CIP4 JDF Editor it is valid for
elements to appear unspecific number of times under another element and the application
allows the user to add even more elements. The applications should not only display which
elements that are valid to insert under another element it should also check if the element
already exists and remove it from the list if it is not allowed to be inserted one more time
under this specific element.
6.1.4.3 Provide Value Suggestions for Every Kinds of Attributes when they are
being changed
The CIP4 JDF Editor only supplies the user with suggestions of possible values an attribute
can have for some attributes. This feature is only available for attributes where the
methods in the Java JDF Library for finding valid values for the attributes where found.
17
6.1.4.4 Support Required Elements to be added
Like the function in the Java JDF Library for getting a list of required attributes for an
element, and are used in the process of adding required attributes in the CIP4 JDF Library,
there is a function for listing required elements for an element. This method could be used
for creating a function in the CIP4 JDF Editor to add required elements to an element.
Unfortunately this has not been done as there are only a few numbers of elements,
according to the JDF specification, that must contain a certain kind of element and using
the function for finding the required elements did not list the same elements as it should
have according to the JDF specification. Due to the time limit and the fact that this does
not involve a big number of elements, this problem was not handled or discussed with the
developers of the Java JDF Library.
6.1.5 Bugs and Errors
Known bugs and errors in the editor part of the CIP4 JDF Editor are mainly connected with
the validation of the edits.
• Some inserted attributes are marked as invalid for the element, even though they
are from the list of valid attributes for that element.
• Attribute values are marked invalid when they should be valid.
• Elements and attributes that have been cut can be inserted anywhere in the tree
structure.
• When the Spawned element is inserted under the AuditPool element the CIP4 JDF
Editor gives validation errors.
• It does not work with inserting elements or attributes under a Spawned element.
6.2 Study Over the Use of the CIP4 JDF Editor in a Multi-
Vendor Environment
A study for the use of the CIP4 JDF Editor has been done, and JDF developers have tried
the CIP4 JDF Editor and their opinion and suggestions over how the CIP4 JDF Editor could
be used has been noted. Also where the JDF file is created and by whom, has been
investigated.
6.2.1 Who Could Use the CIP4 JDF Editor and For What?
After several presentations of the CIP4 JDF Editor, both at Heidelberg Druckmaschinen AG
for people involved in the development of JDF and at a technical meeting of the CIP4
consortium in Barcelona it is obvious that the need for such a tool is massive. The
reactions from the audience have been all positive and there are many that want to know
where they can get the tool. A completely new understanding of JDF as a format is
provided by the viewer part of the CIP4 JDF Editor. The JDF format is easier to grasp when
it is visualized in this way with the In-& Output View and the Process View. Using the CIP4
JDF Editor which displays the JDF file with colors and icons at certain places makes it
easier for the user of JDF to see the structure of the file than just using Internet Explorer
to view the file where only the code is displayed. Many people in the audience at the
different presentations of the CIP4 JDF Editor found this very prominent and some are
using the CIP4 JDF Editor today. The CIP4 JDF Editor also makes it easy to detect errors in
the file and solve them in an easy way.
Suggestions of usages of the CIP4 JDF Editor done by the audience and others who have
tried it are that it could be used in education, development and by customers. Education
means that people who are not familiar with the JDF concept can use the CIP4 JDF Editor,
or used for presentations of the format. As mentioned earlier in this chapter the CIP4 JDF
Editor presents the JDF file in a graphic way that makes it easy to grasp and understand
the different components of the file and how they are connected and involved with each
other. The CIP4 JDF Editor could also be used in development and then it is likely that the
main purpose would be that it would serve as a viewer for error searching of the JDF files.
18
The application would then be complementary to existing systems. A last suggestion is

that the CIP4 JDF Editor could be used by customers, like print shops, in decision making
for new investments. The application could for example help the customer to compare
different vendors and their different configurations of JDF files and then be able to choose
the vendor that has the configuration that suite them best.
Statistics from the CIP4 web site shows that the interest for the CIP4 JDF Editor is high. A
total of 137 different users have successfully downloaded at least one of the five different
versions of the CIP4 JDF Editor that have been published on the web site during the
January 23, 2003 and May 27, 2003. There are three versions of the PC version and two
versions of the Mac version that have been published. 61 users downloaded the first PC
version, the second by 79 users and the third version by 56 users. 17 users downloaded
the first Mac version and nine downloaded the last. Some users downloaded more than
one version of the CIP4 JDF Editor. Two users downloaded five versions, four downloaded
four versions, 14 downloaded three versions, 37 downloaded two versions and 80 users
did only download one version of the CIP4 JDF Editor.
6.2.2 Where does job Tickets Get Created and When is

Validation and Editing Necessary during the Printing
Process?
According to Dr. Meino Spreckelsen [4] the job Tickets or the JDF files are in general
created by software like the printReady from Heidelberger Druckmaschinen AG. The job
Ticket is then modified during the whole printing process, as more information is getting
accessible, so the job Ticked is being extended during the whole process. Every little
change done on the job Ticket has to be validated to ensure that everything is in order and
this is being done by the same software.
6.2.3 The job Tickets Way, from Idea to Printed Product
As figure 8 shows, the JDF workflow begins when the customer is handing in the raw
documents over the product that is to be printed, and the order is created followed by a
job setup. In JDF, the CustomerInfo element, as well as the AuditPool element is being
added to the created JDF file. The raw documents from the customer can be of different
formats, two examples are PDF and TIFF. Next step is to import foreign formats that are
needed for the job, the material is converted to PDF and a preflight of the job is done. Now
the preflight elements PreflightInstance, PreflightConstraint and PreflightDetail are added
to the JDF file. The PreflightConstraint element specifies a test that the application will
perform when analyzing the file. Information about the whole file is recorded via the
PreflightDetail element and the result is added to various result pools. One example is the
PageResultsPool element, which will contain several PreflightDetail elements, to record the
page size used in the file, one for every page size in the file. The PreflightInstance element
is used to record information that is specific to one instance of some file objects. The raw
PDF pages are now prepared with colors and trapping and results in final PDF pages. The
trapping process element has the input resources ColorantControl, FontPolicy, RunList and
TrappingDetails. The ColorantControl resource identifies color model used by the job,
FontPolicy describes the behavior of the font machinery in absence of requested fonts, the
RunList is a structured list of incoming page contents that are to be trapped. The
TrappingDetails describes the general setting needed to perform trapping. The trapping
process produces a RunList, which is a structured list of the modified page contents to
which traps have been added. The ColorSpaceConversion element in JDF is also added at
this point and it has the input resources ColorantControl, ColorSpaceConversionParams
and RunList. The ColorSpaceConversionParams is parameters that define how colorspaces
will be converted in the file. The ColorSpaceConversion element is, like the trapping
process element, producing a RunList. The final PDF pages then have to go through page
proof, with the ProofItem element in JDF, and approval before they can be classified as
approved digital pages and move to the next step in the JDF workflow.
19
Raw documents
Approved digital pages
PS, PDF
TIFF/IT
Raw pages Final pages
Import Prepare Proof

Convert and Colors and Page proof and
Preflight Trapping Approve
Figure 8, JDF workflow, from raw documents to approved digital pages.
Next step in the JDF workflow is to make digital sheets out of the approved digital pages,
see figure 9, and get them approved as well. To do this, the first thing is to assign the
pages and create a page list and from this page list a layout template is done. The Layout
resource is defined either by the LayoutPreparation or by the generic ResourceDefinition
process in JDF. The page list and the layout template then results in final digital sheets. An
imposition proof and approve is done of the final digital sheets in order to get approved
digital sheets. The imposition proof is done with the ProofItem element with the ProofType
set to Imposition instead of Page, which is the value for page proof.
Approved digital pages Approved digital sheets
Final digital sheets
Page list
Assemble Create Imposition Imposition Proof

Assign Layout Template Imposition proof and
Pages Approve
Figure 9, JDF workflow, from approved digital pages to approved digital sheets
An Imposition output is then created out of the approved digital sheets and from this
information the plates, as well as previews, are produced, see figure 10.
20
Approved digital sheets Plates

and
Previews
Impositioning Output
Figure 10, JDF workflow, from approved digital sheets to palates and preview
The preview is first used for presetting of the press, and from this together with the plates,
the ink zone profile can be created, and the job is ready to be printed, see figure 11. The
ink zone profile corresponds to the output resource InkZoneProfile in JDF that is produced
by the JDF process InkZoneCalculation. The InkZoneProfile contains information about ink
coverage along and perpendicular to the ink zones for specific press geometry. The
InkZoneProfile is used as an input resource for the following printing process and the pile
of printed sheets is the output resource from that process, described as a Component
resource in JDF. When the product is printed the steps that are left are finishing, delivery,
billing, archiving, job overview and backup.
For every step in this printing process, which is described above, the JDF file is being
modified, and the information created by one step is used by the next step in the process.
Plates
Ink zone profile Printing
and Printed
sheets
Preview
Presetting
Prepress interface
Figure 11, JDF workflow, from pates and preview to printed sheets
6.3 The Interoperability Matrix
The interoperability matrix resulted in a spreadsheet of 25 JDF supported products and the
processes and resources the product consume and produce, see appendix 2. Information
like a short description over the product as well as which kind of product it is, for example
if it is a prepress product, and what JDF and JMF level the product produces and consumes
are included in the interoperability matrix as well. The interoperability matrix was used by
21
CIP4 at their interoperability testing event in San Jose’ in May 2003 for finding testing
qualified testing partners for every product that was to be tested.
The result of the interoperability matrix was less than expected. All full members of CIP4,
who at that point were 72 companies, were contacted for information but only 21 of them
participated and contributed information to the interoperability matrix. From these 21
companies four of them only could say that they planned on develop the product and could
not contribute any useful information. For this reason it is hard to draw any good
conclusions from it regarding the status of the JDF development today. The companies also
had to fill in if the product fully supported the JDF feature of if the support was restricted
and if the product was consuming or producing the features. The consuming support with
approximately 57 per cent was the dominating kind of support. 43 per cent of the support,
both producing and consuming support was restricted. The restricted support was 56 per
cent for the producing support, which is 23 per cent higher than for the consuming
support. The restricted support from the product is a fairly high and this means that it is
hard to determine the support for JDF from the products. The conclusions made from the
resulted interoperability matrix are presented in chapter 6.3.1 to 6.3.5.
The reasons given by the companies that could not contribute information to the
interoperability matrix was mostly that they did not yet have any finished product that
supported JDF and therefore no information to contribute. Others gave the lack of time, as
a reason for not contributes information. A third reason was that the company did not
want to reveal the information in this stage due to the competition between the different
companies.
6.3.1 The Support for JDF Features
JDF features that the products supported was filled in by the companies and the most
supported one was Process Resources and Processes, which was supported by 14 of the
participating products, also Combined Processes, Partitioning and Audits had a good
support of 11 of the products. Eight products supported ProcessGroup Nodes, seven
supported the Product Intent Resources and only two supported the Capabilities feature of
JDF. Supports for SOAP, which is a new feature for JDF was not supported by any of the
products.
6.3.2 The Support for Intents and Processes
Regarding the intents that were supported by the products only six of 17 were supported
by more than one product. Two products supported ArtDeliveryIntent and DeliveryIntetnt
and three products supported BindingIntent, ColorIntent, LayoutIntent and MediaIntent.
Among the supported processes five products supported the Impositioning process, which
makes it the strongest supported process. ColorSpaceConversion, ConventionalPrinting,
ImageSetting, Rendering and Ripping were all supported by four of the products.
6.3.3 The Support for JDF Process Resources
ColorantControl and Media both have a support from 11 of the products that participated
in the interoperability matrix. RunList is supported by nine of the products and
ExposedMedia by eight. ColorSpaceConversionParams, Component, RenderingParams and
Layout are also well-supported resources by the products. A well-supported resource is in
this case a resource that is supported by five or more companies.
6.3.4 The Support for JMF
In general the support for JMF features was very low among the participating products.
The JMF features Signal-Response together with the JMF Queue Support Commands were
the best-supported JMF features with a support from two of the products.
22
6.3.5 The Lack of Time within CIP4
The poor response to the interoperability matrix from the vendors clearly shows that due
to the fact that no one is working full time with the development with JDF it is hard for the
developers to find the time needed for the development and priorities has to be made all
the time.
6.4 The Evolution of JDF
This chapter will start with discussing the need for JDF from the vendor’s point of view and
the customer’s point of view. It will continue by giving a description over the status of the
development of JDF today, furthermore the focus of the development will be discussed and
finally found problems with the development of JDF will be discussed.
6.4.1 The Need for JDF
The trend in the industry shows that there are less and less hardware being sold [3]. There
are no needs for new hardware because old equipment is still functioning very well. And
there is a recession in the printing industry. This meant that new actions had to be taken
to find new business areas.
6.4.1.1 The Vendors Need for JDF
First of all JDF compatibility will definitely serve as a sales argument this is something that
developers from PPI media, Heidelberger Druckmaschinen AG and Agfa believe.
One of the purposes with JDF is that every kind of vendor should gain from using it.
Unfortunately it looks like it will be hard for small vendors to gain from JDF in the
beginning. Frank Theede at PPI Media [5] believes that the JDF specification is to complex
and that small vendors with only one or two programmers will not have the resources to
get into the JDF specification. Rainer Prosi at Heidelberger Druckmaschinen AG [3] agrees
but thinks that after a while there may be short manuals or cookbooks of how to use JDF
and implement it and then it could be a help for smaller vendors to survive. Koen Van de
Poel at Agfa says that generating JDF is not so difficult and that small MIS vendors do this
already but he also thinks that interpreting it correctly and provide real time feedback is
quite complex and perhaps not so easy for small vendors.
Regarding vendors in the newspaper industry, they will gain from JDF in that way that they
will get a predefined interface. Interfaces to other vendor’s products cost very much to
develop and there is no gain from it. Today this is just something that the vendors have to
do. Computer to plate and computer to film are two areas within the newspaper industry
that would work very well with JDF as well as press control systems.
6.4.1.2 The Customers Need for JDF
The customer will gain from JDF in that way that he will be able to choose between better
and more products, since the competition among vendors will become tougher and they
have to produce better products [5]. Rainer Prosi [3] means that except from mentioned
proposals, for how the customers will be affected by JDF, the customers will not be
affected of the new standard very much because they will probably not be interested in
how the technology works just that it works. In order for the customers/printers to gain
from JDF they will mostly need both MIS and production to use JDF otherwise they will
miss the complete picture and do not have full control and reporting [2].
23
6.4.2 Status of the JDF Development Today
It is hard to describe the status of the JDF development today, because there are several
working groups within CIP4 that separately are in charge for a specific area of the
development, it is also hard to get in touch with the right people that have time to
describe it. This report will look at two of the working groups, the Preflight working group
and the Newspaper working group, and their work. The standard or rather the new version
of the standard will be described and finally the market will be described, how the different
kinds of companies are involved in the development and if the interest of the standard is
spread over the whole industry et cetera.
6.4.2.1 Preflight
The preflight Sub-Working group was created in June 2002. However, the group only got
active in November 2002. Their aim is to standardize the way to specify preflight checks in
a JDF and create a report from the preflight result. The focus for the preflight working
group within CIP4 is to get in sync with the Device Capability group to make sure they use
the same structure as the Device Capability group does to define the checks. Once this is
done, they need to focus on the report. At the moment the Preflight working group is still
at the specification stage. They have covered the way to define the checks with grouping
them in profiles, but they still need to work on the reporting part. Another major step will
be; doing test and making sure all the preflight software’s interpret the JDF the same way
and report the same results.
6.4.2.2 The Newspaper Industry
Since the newspaper industry is a too complex industry and will in some cases be to
complex to be supported by JDF to 100% the newspaper working group within CIP4 has
recently decided to concentrate the JDF development to expressing the interfaces between
Planning System/Mail Room and Planning System/Plate Room Manager in JDF
Planning Mail
System Room
JDF interface
Plate Room
Planning Manager
System
Figure 12, JDF interfaces that the newspaper working group have decided to concentrate
on.
6.4.2.3 Version 1.2 of the Standard
A 1.2 version of the standard is coming and it should be released in the third quarter of
2003. The new in this version will mainly focus on:
• Capabilities, so devices know what they are capable of
• Preflight
• ICS, for better structure
• Transport layer to move JDF around using SOAP
There will not be so much about the newspaper part of the printing industry.
24
6.4.2.4 The Market
The development of JDF supportive products is very important for the majority of the
vendor companies. And most common is that new products are developed so that they
have JDF support. At PPI Media they build all their products on JDF. They have an end-to-
end production system that is based on JDF, except the mailroom, which however is
covered with interfaces. They already have products that are JDF compatible and they are
already selling them to their customers, they are counting on start earning money from
JDF supportive product within two years. At Heidelberger Druckmaschinen AG they develop
both completely JDF based products but also interfaces for cooperate with non-JDF based
products and AGFA also develop all their new products with JDF support.
In total for the printing companies there is a big interest for JDF development and they are
members of CIP4. The only big company that not yet is a member of CIP4 is Quark but
their business area does not need JDF so far. Digital press companies are large companies
and are all members. Smaller companies are not members as frequently as larger ones;
this is mostly due to the high member fee that the companies have to pay annually but
still 50% of the finishing companies are members. Unfortunately the MIS companies are
too small to be full members since they often only have three to four employees.
6.4.3 Focus
Right now the focus is on the development of the new version 1.2 of JDF. Capabilities and
preflight are very much in focus. Interoperability testing of products from different vendors
does also have a big focus right now. According to Koen Van de Poel [2], Agfa is focusing
on the creative face and prepress, their product Delano touches MIS/e-commerce a bit. In
the future they are going to focus on the newspaper industry.
6.4.3.1 Which Kinds of Companies are Likely to Start Using JDF as a Standard?
Koen Van de Poel does not believe that all types of print shops will use JDF supported
products for their production. He believes that larger companies for commercial printing
will be the first ones to start using JDF as a standard. The last ones that will start using it
will probably be smaller print shops and shops that do a lot of different work that is
difficult to automate.
Charles Ouimet at Markzware Software and chairman at the Preflight working group at
CIP4 partly disagrees with Koen Van de Poel [2] he think either the really big standard-
loving companies will start using JDF as a standard but he can also think of the small and
dynamic shops to start using the format. His opinion is that big companies are usually slow
to move. Charles Ouimet’s [1] vision is that a product that supports JDF should also work
in a non-JDF environment, as a stand-alone application for instance.
6.4.4 Time Perspective
As two different milestones Drupa 2004 and Drupa 2008 are picked to try to create a
picture of JDF in the future. Drupa 2004 is close by and a bit easier to predict than it is to
predict what could have happened to the specification until Drupa 2008.
6.4.4.1 Drupa 2004
At Drupa 2004 there will be many 1.2 compliant products exhibited and in all many
products that support JDF and JMF [3] the real time feedback using JMF will be well spread
[2]. Additionally more integration efforts by different companies will be done and ready to
be shown at Drupa 2004. Regarding the Preflight work group they hope the specification
will be completely written down and that there should also be a few companies with JDF
support by then. The specification might need some improvement; “we’ll see how it
integrates in the applications/market” says Charles Ouimet [1].
25
6.4.4.2 Drupa 2008
There are four scenarios that Dr. Rainer Prosi can predict, and he sees them all equally
predictable.
1. JDF is forgotten, it was too complex
2. JDF becomes just another format among others
3. JDF becomes like PDF => everyone wants it (JDF version 5.0)
4. JDF version 2.0, a much simpler standard than 1.x (like .Net)
6.4.5 Problems with the Development of JDF
Although the development of JDF is going very smooth and rapid, and that the cooperation
between the different vendors involved with the development works out without problem
even if the vendors are competitors to one and each other. Various problems have to arise
when it comes to a development of a standard of this dimension and some of these
problems will be discussed in this chapter.
6.4.5.1 The Newspaper Industry
In the newspaper industry the workflow is already highly automated and therefore JDF is
not as much needed in this area of the printing industry as for others. The products are
also very similar to one and another, which also leads to a less significant need for JDF.
There are also very much advertising adds in the newspapers and this is hard to be
handled with JDF, all adds would have to be treated with its own extension and this would
lead to that the JDF file would become very large and to complex to be handled. Also the
time is very short in the newspaper production, which means that the time marginal for
making changes may not exist at all. There are also parts of the newspaper production
that probably never will be included in JDF because that would mean that so many
elements have to be added; one example of this is page assembly [5].
6.4.5.2 The Complexity – Is JDF Too Complex To Be Handled?
The size of the JDF specification is enormous and it is complex to get into. For smaller
hardware companies without a big software development this will be a big problem
because the company will not have the resources required for using the JDF specification,
this is something that is as a major problem with the JDF specification [5]. But it is not
just the specification that is to complex the print job itself is very complex and the
question is if the JDF specification will be able to cover the whole print job. Koen Van de
Poel [2] thinks that the specification process needs perhaps more management, and he
believes that for JDF to succeed it is not so important to support every possible value. He
says “we need to concentrate on interoperability and clarifying the standard with examples
et cetera”. Another problem that is worth mention is the fact that XML has moved forward
and new JDF are not compliant with the new XML, this is something CIP4 does not care
about at the moment, according to Dr. Rainer Prosi [3].
6.4.5.3 The Multi-Vendor Development
The work with developing the JDF standard is done by the members of CIP4; this means
that the standard is developed by a multi-vendor organization. In this case one problem is
that no one is working full time with the development of the standard so they cannot be
focused at 100 percent, this leads to that the most dedicated ones are the ones that will
do most of the work and make most of the decisions. CIP4 as an international organization
can itself be a problem due to the member fee for companies of a smaller scale, which
cannot afford it and therefore will not be able to join CIP4 in order to contribute to the
development of JDF. Charles Ouimet [1] think the biggest problem the Preflight working
group faced so far is not getting more than four to five enthusiasts people in the group and
they need more because creating a specification like this involves a lot of time and
thinking.
26
The problem with the lack of enthusiasts’ people involved as Charles Ouimet described and
the fact that no-one is working full time with the development of JDF was very much
experienced during the work with gathering information to the interoperability matrix.
6.4.5.4 Flexibility – Multi Dialects/Extensions
The flexibility of the JDF specification, the use of JDF extensions and optional elements,
leads to a standard that contains several different dialects, one dialect for every vendor
that is developing products that supports it. This could make it difficult for products from
different vendors to communicate because every product does not support all extensions
and optional element that others support. For this reason extensions are something that
CIP4 discourage [3]. Koen Van de Poel [2] emphasizes that there are too many different
ways to describe a product/intent. “Indeed very flexible for the producer side but a
nightmare for the consumer side” he says. This could be helped with ICS, which is coming
strongly in the 1.2 version of the JDF specification.
6.4.5.5 Lack of MIS Companies Involved
Although the MIS companies are becoming more and more active this year there is still a
lack of them within the JDF development. The lack of MIS companies that are involved in
the development makes it harder do develop the JMF part of JDF
27
7 Conclusions/Discussion
7.1 Conclusions from the Interoperability Matrix
Due to the low participation of the vendors in the interoperability matrix the resulting
conclusions show it cannot be treated as a good indicator of what the development of JDF
looks like. The result is very much dependent on which kinds of companies contributed
information to the interoperability matrix. If other companies, instead of these ones had
contributed information, the result would probably be highly different from how it looks
today. For a more truthful analogy to be made of the development of JDF, a much higher
participation rate must be obtained. The easiest way of doing this is to make the
participation in the interoperability matrix compulsory for companies that want to
announce that they have JDF supportive products on the CIP4 web site.
The reason for the low participation of the work with the interoperability matrix is a result
of several factors. One is that the vendors do not yet have their JDF supportive product
ready, so they do not have anything to contribute. A second reason is that the vendors do
not want to reveal their products to others at an early stage, due to competition. A third
reason is the lack of time or interest by the vendors to participate in an interoperability
matrix. Also, the fact that the task of filling in a form about the company’s JDF supported
products is not the most stimulating task and therefore automatically is given a lower
priority compared to other more interesting tasks.
7.2 Discussion over the Resulting CIP4 JDF Editor
The features discussed in the chapter 6.1.4 are those not handled by the CIP4 JDF Editor.
This is mainly due to the time limit this master project had. The decision to edit only from
the Tree View is an important result. More effort could be made to enabling editing from
the Process View, the Error View, and the In- & Output View as well as from the Attribute
View, but this would mean that both editing and other features, like the search function
would be suffering. Another conclusion that can be drawn is that it would be better to
leave out the validation of the JDF files and focus only on the view and editing parts of the
CIP4 JDF Editor, as the development for the validation was very time consuming and the
result is not that good.
7.2.1 Conclusions over the Usefulness of the CIP4 JDF Editor
The three proposed suggestions of the usage areas for the CIP4 JDF Editor are; education,
development and “used by the customer”, given in chapter 5.4.1.1 “Who could use the
CIP4 JDF Editor and for what?” The employment of each of these suggested areas have
different likely nesses. The likeliness that the last suggestion would become reality is hard
to predict and it also seems to be the least likely to be realized. This is mostly due to the
opinion of the vendors that the customers will not be affected of the new standard, they
will just use it; but it is still an option. The second suggestion that the application would be
used in development is very likely and is also fact, as it is already being used, by
developers on a small scale. The first suggestion mentioned, seems to be reasonable,
since it is easier to look at a JDF file in the CIP4 JDF Editor in order to get a feeling for how
the file is built and what it is, rather than to just look at the source code of the file and try
to understand it.
As it says in chapter 5.4.2 “Where does job Ticket get created and when is validation and
editing necessary during the printing process?” the job Tickets are generally created by
existing software and validation and editing is necessary during the whole printing process.
The fact that there is software on the market that handles the creation of a JDF file and
also the validation and editing of it during the printing process, means that conclusions can
be drawn that this is an area where the CIP4 JDF Editor will not be used. The use of the
28
CIP4 JDF Editor in the printing process will be before the printing process has started and
it will be for viewing and editing.
At this early stage of the CIP4 JDF Editor it is to be most expected that it will be used
outside the workflow and printing process, being used instead, for development.
29
8 Recommendations
The application is in an early stage of development and therefore it does not yet handle
everything that it is meant to handle. To continue on the development of the CIP4 JDF
Editor the best thing is to start implementing the delimitations mentioned in chapter 4,
which are following features:
• Support validation
• Support foreign and private namespaces
• Support refElements
• Support Partition display
• Undo and redo
• Drag and drop
• Source View
• Hide and show attributes in tree view
If these delimitations are implemented, many of the bugs and errors in the CIP4 JDF Editor
will be solved as well as the issues that are discussed in chapter “What in not handled by
the CIP4 JDF Editor”. A new version of the CIP4 Java JDF Library is soon to be released
and using methods form this newer version will also improve the performance of the CIP4
JDF Editor.
Also the Macintosh version of the CIP4 JDF Editor needs to be checked for bugs and errors,
because the testing of this version has not been done properly.
One other feature that could be interesting in an application like the CIP4 JDF Editor is the
ability to execute the JDF process associated with the JDF file displayed in the editor with
the return URL setup to notify the CIP4 JDF Editor so that it could be automatically
reloaded after process execution. This would allow the user to see how process execution
modifies the JDF and allow a quick means for testing processes. There are methods in the
CIP4 Java JDF Library for submitting the JDF to process execution.
The interoperability matrix will need to be updated, and it is intended that the CIP4
members shall do that themselves at the CIP4 website. To gather information of this kind
it is recommended that it should be obligatory for companies to contribute information to
the matrix when they publish that they have JDF supported products. If this would not be
obligatory it will be very hard to gather the information.
30
9 Reference:
9.1 Interviews
[1] Charles Ouimet, at Markzware and chairman at the Preflight working group at CIP4,
2003-04-23
[2] Koen Van de Poel, chairman Prepress working group, Agfa, 2003-04-29
[3] Dr. Rainer Prosi, Senior Software Architect at Heidelberger Druckmaschinen AG and
Chief Technical Officer at CIP4, 2003-04-08
[4] Dr. Meino Spreckelsen, at Heidelberger Druckmaschinen AG, 2003-04-09
[5] Frank Theede, at PPI Media and chairman at the Newspaper working group at CIP4
9.2 Literature
[6] JDF Specification 1.1, www.cip4.org, 2003-04-07
9.3 Electronically References:
[7] www.cip4.org/, 2003-04-07
31
Appendix 1: The Interoperability Matrix
32
Audits
Intents
Processes
Partitioning
Capabilities
JDF Features
Support for SOAP

Combined Processes
ProcessGroup Nodes
Process Resources and

Product Intent Resources
Product
C, R
C, R
C, R
ApogeeSeries3
C, R
C, R
C, R
ApogeeX
P
C
C
C
C, R
JDF Manager
PL
MarkzNet
PL
anonymous1
C, R
C, R
C, R
C, R
anonymous2
P, R
P, R
C, R
P/C,R
Normalizer
P
C
C
C
FastLane
PL
Shinohara Machinery
C
P/C,R
P/C,R
P/C,R
ElecRoc
PL
PrintSapiens
P, R
P, R
P, R
C, R
C, R
C, R
DALiM FiCELLE v3.0

R
P, R
P, R
C, R
C, R
P/C,
DALiM TWiST v5.0

P/C
PrintNet
Vio Digital Workflow Application Suite / 4.2
anonymous3
JDF-Link
C
C
C
C
C
C
P/
P/
P/
anonymous4
P
R
P,
Hagen OA 7.1 with Press Connector
anonymous5
P/C
Best Colorproof / Screenproof 4.6.3

P,R
P, R
P, R
P, R
C, R
OS ABSYS
Best Remoteproof 1.2

P
C
C
C
MetaDimension
,C
P/C
P/C
P/C
P/C
P/C
C, R
Most
Prinect PrintReady System

ArtDeliveryIntent P/C C, R
BindingIntent C, R P/C P, R
ColorIntent C P/C P, R
DeliveryIntent P/C P, R
EmbossingIntent P/C
FoldingIntent P/C
HoleMakingIntent P/C
InsertingIntent P/C
LaminatingIntent P/C
LayoutIntent C P/C P, R
MediaIntent C,R P/C P, R
NumberingIntent P/C
PackagingIntent P/C
ProductionIntent P/C
ProofingIntent P/C
ShapeCuttingIntent P/C
SizeIntent P/C
Process
Approval P, R
ColorSpaceConversion P/C,R P, R C P/C
ColorantZoneDetails
Combined RIPing P/C
P/C,
ConventionalPrinting P/C R P P
DigitalDelivery P/C, R
DigitalPrinting P/C
IDPrinting P/C
34
ImageSetting C C C P
P/C
Imposition C C ,R C P
InkZoneCalculation P, R
P/C
Interpreting C C ,R
P/C
LayoutPreparation ,R
Preflight P, R P
Proofing P, R
PSToPDFConversion P/C,R P, R
P/C
Rendering C C P, R ,R
RIP'ing C C P, R C
Separation C C P, R
Screening C C P,R
P/C
Trapping C C ,R P/C
ResourceDefinition P/C,R
Group C
Combined C C
Collection C
CoverApplication C
EndSheetGlueing C
P/C
Folding ,R P, R
Gathering C
P/C
HoleMaking ,R
Inserting C
P/C
Stitching
C ,R
Trimming C P/C
35
,R
BoxPacking P, R
Cutting P, R
JDF Process Resources
All C
CuttingParams P, R
ByteMap P/C
ColorantZoneDetails C C
P/C P/C,
ColorantControl C C P/C P, R C, R ,R P/C, R P, R R P/C P/C
Color P/C P/C
ColorantParams C C
ColorantOrder C C
ColorPool C C P/C P/C
ColorSpaceConversionPar P/C,
ams C P, R P/C, R R C P/C
ConventionalPrintingPara
ms C, R P
P/C,
Component P/C,R R P P,C P, R P/C
P/C
Device P ,R P, R
DigitalDeliveryParams P/C, R
DigitalPrintingParams P/C,R P/C
P/C,
ExposedMedia C C C, R P/C, R P, R R P/C P/C
FileSpec Layout C C P/C P/C
FitPolicy C P/C
P/C
FoldingParams
,R
FontParams C P, R P, R
FontPolicy P, R
HoleMakingParams P/C
36
,R
IDPrintingParams P/C
ImageCompressionParam
s C
ImageSetterParams P/C, R P, R P/C P/C
Ink C P/C
InkZoneCalculationParam
s P, R
InterpretingParams C C P/C
LayoutPreparationParams P/C, R C
Layout C C C, R C P/C
LayoutElement C C P/C P/C
P/C,
Media C C P, R C, R P P/C P/C, R P, R R P/C P/C
ObjectResolution C C C P/C
PDFInterpretingParams C C
PDFToPSCoversionParam
s C P/C
PreflightProfile P, R
P/C,
ProofingParams P, R P/C, R R
PSToPDFConversionPara
ms C P, R
RenderingParams C C P/C, R P, R C P/C
P/C,
RunList
C C P/C P, R P/C P/C, R R P/C P/C
ScreeningParams C C P, R P/C
ScreenSelector C C P
SeparationControlParams C C P, R
SeparationSpec P
Sheet P, R C P/C
Signature C C
37
Surface C P/C
P/C
StitchingParams
,R
TransferCurvePool P, R
TrapRegion C C P/C
TrappingDetails P/C
TrappingParams C C P/C, R P/C
P/C
TrimmingParams
,R
Partitioned Resource and
Keys
P/C,
Separation
R
SheetName
C, R
P/C,
Side
R
AuditPool update in
supplied JDF file by
receiver
Notification
P, R
Act on Scheduling
attributes supplied in
NodeInfo Yes
Start C, R
End
C, R
JMF: Responses to NodeInfo queries in the P/C,
supplied JDF file P/C, PL PL
StatusQuery C, R
JMF: Capabilities report in response to a All All

KnownDevices Query P/C P/C
38
JMF: Other Query & Response with

Subscription/Signal
Events C, R
KnownMessages
C, R
KnownJDFServices
C,R
Status
C, R
P/C, P/C,
Signal-Response
R R
JMF Queue Support Yes, Yes,
Commands All C All C C P/C
SubmitQueueEntry
C, R C, R
QueueStatus
C, R
Execution Model
Serial Processing P/C,R

Parallel Processing P/C,R
Test Running
Support for test runs P/C, R
Others
output resource location
etc. update in supplied
JDF file P/C
P = Produce, C = Consume, R = Restricted Support
39
Appendix 2: Glossary
CIP4 International Cooperation for Integration in Prepress, Press and
Postpress, develops JDF
JDF Job Definition Format, a specification developed by CIP4
Job Ticket A file which contains information about a print job or a print process
MIS Management Information Systems, Production supervising system with

connections to the economical system
PJTF Portable Job Ticket Format, a specification developed by Adobe and

precursor to JDF
PPF Print Production Format, specification developed by CIP3 and precursor

to JDF

The CIP4 JDF Editor, The Editing Part: Annaa@kth - Se

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

The CIP4 JDF Editor, The Editing Part: Annaa@kth - Se

Uploaded by

Copyright:

Available Formats

The CIP4 JDF Editor, the

- The Development of a CIP4 JDF Editor, Focusing on the

CIP4 JDF Editor,

Examiner: Prof. Nils Enlund

Applikationens funktioner definierades tillsammans med experter på Heidelberg

• Lägga till element/resurser/länkar/attribut

<?xml version="1.0" encoding="UTF-8" ?>

1.1.1 JDF’s Most Prominent Features

The most prominent features about JDF are as follows:

1.1.2 The structure of JDF

1.1.3 Product Intent

1.1.4 JDF Extensibility

6.1 The CIP4 JDF Editor

6.1.1 An Overview of the Graphical User Interface

6.1.1.1 The Tree View

6.1.1.2 The In- & Output View

to the right, see figure 3, or if a resource is selected it displays a resource centered

6.1.1.3 The Process View

6.1.1.4 The Error View

6.1.1.5 The Attribute View

6.1.2 The Editor Part

Figure 6, the right mouse menu

6.1.2.2 Adding and Modifying Elements

6.1.2.2.1 Renaming Elements

6.1.2.3 Adding and Modifying Attributes

6.1.2.4 Adding Resources

same procedure as described in chapter 6.1.2.1 “Synchronization between the JDF

6.1.2.5 Adding Links

6.1.2.6 Create New JDF/JMF Files

6.1.2.7 Cut, Copy, Paste and Delete

6.1.2.8 Save and Save As

6.1.3 How the Connection between Editing and Validation of the

6.1.4 What does the CIP4 JDF Editor not handle?

6.1.4.1 Support for Foreign Namespaces

6.1.4.4 Support Required Elements to be added

6.1.5 Bugs and Errors

The application would then be complementary to existing systems. A last suggestion is

6.2.2 Where does job Tickets Get Created and When is

6.2.3 The job Tickets Way, from Idea to Printed Product

Import Prepare Proof

Figure 8, JDF workflow, from raw documents to approved digital pages.

Final digital sheets

Assemble Create Imposition Imposition Proof

Approved digital sheets Plates

6.3 The Interoperability Matrix

6.3.1 The Support for JDF Features

6.3.2 The Support for Intents and Processes

6.3.3 The Support for JDF Process Resources

6.3.4 The Support for JMF

6.3.5 The Lack of Time within CIP4

6.4 The Evolution of JDF

6.4.1 The Need for JDF

6.4.1.1 The Vendors Need for JDF

6.4.1.2 The Customers Need for JDF

6.4.2 Status of the JDF Development Today

6.4.2.2 The Newspaper Industry

6.4.2.3 Version 1.2 of the Standard

6.4.2.4 The Market

6.4.4 Time Perspective

6.4.4.1 Drupa 2004

6.4.4.2 Drupa 2008

6.4.5 Problems with the Development of JDF

6.4.5.1 The Newspaper Industry