Page 533 
Page 533 
PJTF Data Type 
JDF Representation 
Comment 
Dictionary 
element 
All PJTF objects are dictionaries.  These dictionaries generally 
become resources or processes as specified above. 
In addition, some PJTF objects contain embedded dictionaries 
whose keys are not specified (examples include TrappingParameters 
and ColorantDetails).  These dictionaries are converted to arrays of 
elements, with the key name from the PJFT dictionary becoming an 
attribute of the subelement. 
Stream 
URL 
PJTF supports PDF streams by reference to an object in a PDF file.  
The same mechanism is supported in JDF, with the JDF URL data 
type being used to identify the PDF file. 
Rectangle 
rectangle 
Filespec 
URL 
Text 
string 
String 
string 
Date 
date 
Phone number 
Phone number 
The standard for the representation of phone numbers in PJTF is 
used here as well. 
C.4  Translating the Contents Hierarchy 
The  contents  of  a  PJTF  job  are  represented  in  the  “contents  hierarchy”.    The  hierarchy  is  headed  by  the 
JobTicketContents object, with Document, PageRange and JTFile objects occurring below.  The hierarchy implicitly 
specifies the sequence of source pages for the job. 
The contents sequence comprises all the pages specified by the first, then second, then last PageRange for the 
first  Document,  followed by  the  pages  specified  by  the first,  then  last  PageRange  for  the  second  Document, 
followed by the pages for the first, then last PageRange for the last Document. This sequence of source pages is 
consumed when the job is printed via PrintLayout (discussed below). 
The contents hierarchy must be translated into a JDF RunList resource. Each LayoutElement entry in a RunList 
can reference a file via the FileSpec:URL attribute and a set of pages in the file via the Pages element. There are 
several additional issues related to this translation which are discussed below. 
C.5  Representing Pages 
In PJTF, source pages are represented as a hierarchy of Document and PageRange objects.  Pages are referenced 
by page number out of files; files are represented in JTFile objects.  PageRange objects can reference a single 
page, or a set of contiguous pages. 
In JDF, source pages are represented as a set of partitions of the RunList, which reference files via URL, and 
pages from the files via an IntegerRangeList (such as ‘1 3~5 7~ -1‘). 
As a consequence of this difference, pages from more than one PJTF PageRange object can be represented in a 
single RunList resource, assuming that all the other keys for the multiple PageRanges have the same values. 
C.6  Representing Preseparated Documents 
In preseparated workflows, all planes of each page may occur in the same file, or there may be a separate file for 
each plane.  When all the planes occur in a single file, PJTF JTFile objects use a PlaneOrder object to specify 
which pages in the file represent each colorant plane for each source page.  When each plane occurs in a separate 
file, the JTFile objects use a FilesDictionary to associate files with each colorant. 
In JDF, both of these cases are handled through the RunList resource.  In the case where the planes occur in 
separate files, the RunList is partitioned; and each partition contains the name of the colorant and the URL for the 
file for that colorant.  In the case where the colorant planes are intermingled via PlaneOrder objects, the RunLists 
Pdf secure signature - C# PDF Digital Signature Library: add, remove, update PDF digital signatures in C#.net, ASP.NET, MVC, WPF
Help to Improve the Security of Your PDF File by Adding Digital Signatures
create pdf the security level is set to high; decrypt pdf password online
Pdf secure signature - VB.NET PDF Digital Signature Library: add, remove, update PDF digital signatures in vb.net, ASP.NET, MVC, WPF
Guide VB.NET Programmers to Improve the Security of Your PDF File by Adding Digital Signatures
convert secure webpage to pdf; pdf password unlock
Page 534 
Page 534 
are partitioned, but only a single URL is used for each RunList partition.  Each PlaneOrder object will become one 
RunList partition. 
C.7  Representing Inherited Characteristics 
In PJTF, many of the characteristics of source pages—including MediaBox, ColorantControl, and InsertPage—
may occur at all levels of the contents hierarchy. This inheritance scheme is not provided in JDF.  Therefore, the 
correct values for each of the attributes must be translated to the appropriate element for each RunList element. 
C.8  Translating Layout 
PJTF  provides  two  mechanisms  to  image a  set  of  source  pages  onto  a  larger  surface  for  printing:  Layout  and 
PrintLayout.  Layout is a mechanism for explicitly associating specific source pages with specific locations on the 
surface.  PrintLayout is a method for automatically positioning a sequence of source pages onto a series of surfaces. 
Layout is  represented  as a hierarchy of  PJTF objects:   Signatures, Sheets, Surfaces  and PlaceObjects.   The 
Layout hierarchy may have one or more Signature objects.  Each Signature must have one or more Sheets.  Each 
Sheet must have 1 or 2 Surfaces.  Each Surface may have 0 or more PlacedObjects. 
PlacedObjects directly reference source pages by referring to a Document object via its Doc key, and a specific 
page within the sequence of pages specified by all the PageRanges in Pages arrays for that Document. 
JDF  defines  resources  which  are  direct  translations  of  Signature,  Sheet  and  Surface.    PlacedObjects  and 
MarkObjects are subelements  of  the  Surface resource.  Note:  PlacedObjects  identify specific  source  pages  via  a 
combination of Ord and either Doc or MarkDoc.  Ord identifies one page out of the sequence of pages specified by 
all the PageRange objects for the document identified by either Doc or MarkDoc. 
In the JDF PlacedObject subelement, the Ord attribute is an index into the entire sequence of pages specified by all 
the partitions with IsPage = true in the RunList.  So there is a translation required between the PJTF Ord value 
and the JDF Ord attribute. 
Similarly, in the JDF MarkObject subelement, the Ord attribute is an index into the entire sequence of pages 
specified by all the partitions in the RunList for marks.  So there is a translation required between the PJTF Ord 
value and the JDF Ord attribute. 
C.9  Translating PrintLayout 
PrintLayout uses the same hierarchy of objects as Layout, but with the restriction that there can be only a single 
Signature.  The Signature is used as a template that is repeated to consume all the source pages specified by the 
contents hierarchy for the job. 
In addition, the PlacedObjects that occur in a PrintLayout hierarchy are not references to specific source pages.  
Instead, they represent the intent that a page from the sequence of source pages specified by the contents hierarchy be 
consumed and placed onto the Surface each time the Signature is executed. 
In JDF, PrintLayout is represented via the same set of resources as Layout, except that the top of the hierarchy is 
an AutomatedLayout resource instead of Layout.  This resource is constrained to have only one Signature resource. 
Note  that  when  translating  PJTF  PlacedObjects  to  PlacedObject  subelements  of  a  Surface  resource  in  the 
AutomatedLayout hierarchy, the Ord values from the PJTF PlacedObjects need not be modified. However, as in the 
creation of Layout, the Ord attribute for JDF MarkObject subelements are indices into the entire sequence of pages 
specified by all the partitions in the RunList for marks.  So there is a translation required between the PJTF Ord 
value and the JDF Ord attribute. 
C.10  Translating Trapping 
Trapping  controls  are  represented  in  PJTF  as  several  objects:  Trapping,  TrappingDetails,  ColorantDetails  and 
DeviceColorants;  TrappingParameters  and  ColorantZoneDetails;  and  TrapRegions.    These  objects  can  occur  in 
multiple places in the PJTF job, and they work together to determine, for each page in the job, whether it will be 
trapped and how.  There is also a key in the JobTicketContents object, TrappingSourceSelector, which determines 
which set of trapping controls will be honored. 
The trapping controls in PJTF are the same, whether the trapping will be done pre-RIP or in-RIP. In translating 
PJTF trapping controls to JDF, there are several tasks to perform: 
•  Create the required Trapping node  
XDoc.HTML5 Viewer for .NET, All Mature Features Introductions
to search text-based documents, like PDF, Microsoft Office typing new signature, deleting added signature from the text selecting in order to secure your web
decrypt pdf password; decrypt pdf file online
C# Create PDF Library SDK to convert PDF from other file formats
for C# developers to create a highly-secure and industry What's more, you can also protect created PDF file by adding digital signature (watermark) on PDF
pdf security; create encrypted pdf
Page 535 
Page 535 
•  Add the resources to represent the TrappingParameters which will be used 
•  Create the resources which represent the TrapRegions which will be used 
•  Determine the pages to be trapped 
•  Determine which controls to use for each page  
•  Add references to the pages in the RunList in the TrapRegion resource 
Note:  The contents hierarchy for the PJFT job must be translated into RunLists before trapping objects can be 
translated. Paths in JDF are specified as a set of path operators.  PJTF TrapZone paths are a sequence of coordinates 
with an implied moveto at the beginning, and an implied closepath the end. 
DocImage SDK for .NET: HTML Viewer, View, Annotate, Convert, Print
from popular documents & images in .NET, including Microsoft Word, Excel, PPT, PDF, Tiff, Dicom type(s). Later, you can make an order in our secure online store
change security settings on pdf; secure pdf
WinForms .NET Imaging SDK | Royalty-free Image SDK
Support common image and document file format, including BMP, Gif, PNG, PDF, JPEG 2000 our License Agreement and choose a suitable one in our secure online store
secure pdf remove; pdf password security
Page 536 
Page 536 
Appendix D  Converting PPF to JDF 
This appendix gives non-normative advice on how to convert CIP3 PPF 3.0 files to JDF encoded files.  Since JDF was 
designed  with  the  intention  of  providing  the  highest  possible  level  of  compatibility  with  PPF,  many  of  these 
conversions are relatively straightforward.  From the point of view of JDF, CIP3’s PPF is mainly resource-based.  Most 
of the PPF structures were, therefore, translated to JDF resources of a corresponding process.  Meanwhile, the PPF 
product  definition  operations  are  easily  translated  to  JDF  processes  of  the  same  name,  as  quoted  in 
CIP3ProductOperation.  This kind of conversion is possible because the component structure of PPF is adopted by 
JDF, with some enhancements.  Parameters of PPF product definition operations (CIP3ProductParams) are given the 
abbreviated name “Params,” and  this name is  appended to the  CIP3ProductOperation  name.    Thus SideSewing 
becomes SideSewingParams.   
In many cases, PPF key names became JDF attribute or element names with the  “CIP3” prefix removed.  An 
example of this kind of  translation is provided below, and the  CIP3 product structure shown in the example  is 
expressed as a JDF process in Figure D.1, following the example. 
Example:  A CIP3 PPF product definition operation 
/CIP3Products [ 
<< 
/CIP3ProductName (sewed book block) 
/CIP3ProductOperation /ThreadSewing 
/CIP3ProductParams << 
/NumberOfNeedles 4 
/GlueLineRefSheets [ 0 ] 
/GlueLine << 
... 
>> 
/BlindStitch false 
/Sealing false 
>> 
/CIP3ProductComponents 
<< 
/SourceType /PartialProduct 
/SourceProduct (book block)
... 
>> 
>> 
<< 
/CIP3ProductName (book block) 
% ...  the definition of the book block operation would go here ... 
>> 
] def
Component
Component
ThreadSewing
ThreadSewingParams
Figure D.8.1  JDF node of a CIP3 product structure 
In Figure D.1, the input Component represents the “book block,” the output Component represents the “sewed 
book block,” and ThreadSewingParams covers all information of the CIP3ProductParams structure. Whenever 
possible, the formal conversion and translation conventions described above were followed, but because extensions 
and operations new to PPF are included in JDF, some exceptions were made.  These exceptions are explained in 
Java Imaging SDK Library: Document Image Scan, Process, PDF
View, edit, re-order, clean-up and convert documents/image from PDF, Tiff, Png Read our license Agreement and choose a suitable one in our secure online store!
decrypt password protected pdf; change pdf security settings reader
.NET DICOM SDK | DICOM Image Viewing
Developed based on the latest DICOM specification, RasterEdge DICOM codec provides complete DICOM Data Sets, secure communication and more.
creating secure pdf files; convert locked pdf to word doc
Page 537 
Page 537 
detail for each PPF structure in the sections that follow.  Before they are explained, however, a translation of PPF 
data types is provided. 
D.1  Converting PPF Data Types 
The following table shows all PPF data types, and how they are transformed.  All measuring units of CIP3 must be 
converted to the JDF native unit point (1/72 inch).  Comments are only provided when there is something unusual or 
noteworthy about the translation; thus, not all translations require comment. 
Table D.1  Conversion of PPF Data Types 
PPF Data Type 
JDF Data Type 
Comments 
boolean 
boolean 
Integer 
integer 
Real 
double 
The exponent symbol must be a capital “E” in XML. 
Number 
double 
The exponent symbol must be a capital “E” in XML. 
Name 
enumeration or 
NMTOKEN 
When PPF Names are used as a closed set of predefined values, they are 
converted to an enumeration.  Otherwise, they are converted to an 
NMTOKEN. 
String 
string 
Some PostScript string characters cannot be used in XML.   
Array 
Sequence of 
elements or 
IntegerList or 
DoubleList  
If the array consists of homogeneous integers or doubles, it is converted 
to an IntegerList or DoubleList, otherwise to a sequence of 
corresponding elements. 
Dictionary 
element 
In most cases, the structure of a Dictionary is directly converted to a 
XML element.  Exceptions to this rule are described in the following 
sections. 
D.2  PPF Product Definitions 
The information stored in CIP3Products and CIP3FinalProducts is implicitly expressed by the structure of the 
JDF tree.  Each product definition step is converted to a JDF node, and a product node is created for every final 
product of a PPF file.  This is also the case for each partial product that is used in two or more final products.  The 
following  table  provides  information  that  explains  how  to  accomplish  these  transformations  and  make  these 
conversions.  The content of the entities CIP3ProductJobName, CIP3ProductJobCode, CIP3ProductCopyright 
and  CIP3ProductCustomer must  also  be  copied to the  parent  product node.   The sections  that follow  contain 
information about the conversion requirements of prominent postpress processes. 
Table D.2  JDF Representation of a product definition step 
PPF Key 
JDF Representation 
Comments 
CIP3ProductName 
This is expressed by an output 
resource link. 
CIP3ProductOperation 
JDF node 
See Section 3.1  JDF Nodes
CIP3ProductParams 
Resource identified by the name 
of the JDF node + “Params” 
For example, during a CIP3ProductOperation 
of the type “SaddleStitching”, the JDF 
representation of the CIP3ProductParams is 
SaddleStitchingParams 
CIP3ProductComponent 
Component 
See Section D.2.1, below 
CIP3ProductJobName 
Comment element of the JDF 
node 
PDF Image Viewer| What is PDF
information; Royalty-free to develop PDF compatible software; Open standard for more secure, dependable electronic information exchange.
add security to pdf in reader; pdf unlock
DICOM Image Viewer| What is DICOM
SDK and Web Document Viewer provide high-quality, full-featured and secure medical image into other file formats, including Bitmap, Png, Gif, Tiff, PDF, MS-Word
change security on pdf; create secure pdf
Page 538 
Page 538 
PPF Key 
JDF Representation 
Comments 
CIP3ProductJobCode 
JobID or JobPartID attribute of 
the JDF node 
If the output of this step is a final product and it is 
only final product, it should be converted into 
JobID of the root node.  Otherwise, it is 
converted into a JobPartID of the corresponding 
process node. 
CIP3ProductCopyright 
Comment element of the JDF 
node 
CIP3ProductCustomer 
CustomerInfo element of the 
JDF node 
Note that the CustomerInfo element is 
structured, while the CIP3ProductCustomer is 
not. 
CIP3ProductVolume 
Amount attribute of the output 
Component resource link 
D.2.1  Comparison of the PPF Component to the JDF Component 
The structure of  the PPF Component is very  similar  to  the structure of  the  JDF Component, so it is easy  to 
convert one to the other.  The following table gives advice on how to do this.  Some information stored in the PPF 
Component must be used for linking the correct resources to a process.  Other implicit information, such as the 
bounding box of the component or an overfold, must be calculated and explicitly specified in the subelements of the 
Component.  Furthermore,  the appropriate algorithms can be very complex for some operations, such as folding. 
For further information about the Component resource, see Section 7.2.28 Component
Table D.3  Converting a PPF Component 
PPF Key 
JDF Representation 
Comments 
SourceType 
ComponentType attribute of Component  - 
SourceSheet 
SourceSheet attribute of Component 
SheetPart attribute of Component 
Calculable out of the cut block structure. 
SourceBlock 
Expressed by an input resource link to an 
output Component of a previous Cutting 
process. 
see Section D.3.6 Cutting Data 
SourceProduct 
Expressed by an input resource link to a 
Component. 
Params 
Transformation attribute of Component 
In most CIP3 operations, there is only one 
component parameter called Orientation.  This 
matrix is renamed to Transformation.  The only  
exception is the EndSheetGluing process.  See 
Section EndSheetGluing for more information. 
D.2.2  Collecting 
To convert a Collection operation, follow the previous descriptions.  This process contains no special considerations 
to take into account. 
D.2.3  Gathering 
To convert a Gathering operation, follow the previous descriptions.  This process contains no special considerations 
to take into account. 
D.2.4  ThreadSewing 
Convert the entries of CIP3ProductParams structure directly to the ThreadSewingParams resource.  Add this 
resource  as  an  input  resource  link  to  the  originated  ThreadSewing  process.    See  Section 7.2.143  
ThreadSewingParams for more information. 
Page 539 
Page 539 
D.2.5  SaddleStitching 
Convert  the  entries  of  CIP3ProductParams  structure  directly  to  the  StitchingParams  resource.    Set 
StitchType=”Saddle”.  Add  this  resource  as  an  input  resource  link  to  the  originated Stitching  process.    See 
Stitching for more information. 
D.2.6  Stitching 
Convert  the  entries  of  CIP3ProductParams  structure  directly  to  the  StitchingParams  resource.  Set 
StitchType=”Side”. Add this resource as an input resource link to the originated Stitching process.  See Section 
Stitching for more information. 
D.2.7  SideSewing 
Convert  the  entries  of  CIP3ProductParams  structure  directly  to  the  ThreadSewingParams  resource.    Add  this 
resource as an input resource link to the originated ThreadSewing process.  See ThreadSewing for more information. 
D.2.8  EndSheetGluing 
The EndSheetGluing CIP3 operation is the only operation that requires more information than Orientation in the PPF 
Component Params.  This additional information of the front and the back end sheet components is transferred to the 
EndSheetGluingParams resource, as described in the following table.  See Section 7.2.52  for more information. 
Table D.4  Converting the PPF EndSheetGluing operation to JDF 
PPF Key 
JDF Representation 
Comments 
Offset 
Offset attribute of the EndSheet element 
of EndSheetGluingParams 
GlueLine 
GlueLine element of the EndSheet 
element of EndSheetGluingParams 
See Section 7.2.52 for information on how to 
convert the GlueLine structure. 
D.2.9  AdhesiveBinding 
The PPF main adhesive binding operation dictionary is translated to the AdhesiveBindingParams resource.  All 
single suboperations  that were  resident in the PPF  Processes array are converted to special  elements  inside  the 
AdhesiveBindingParams  (see  Section 7.2.3  AdhesiveBindingParams).    For  each  type  of  adhesive  binding 
suboperation  there  exists  one  extra  element.    The  suboperations  SpinePreparation  and  GlueApplication  can 
simply be translated by removing the ProcessType entry and converting all other entries directly to the appropriate 
element.   
The  following  tables  show  how  to  convert  the  main  operation  and  its  other  suboperations.    Because  new 
features were added, the CIP3 Lining operation was renamed to SpineTaping. 
Table D.5  Converting the PPF AdhesiveBinding operation to JDF 
PPF Key 
JDF Representation 
Comments 
Processes 
-  BackPreparation 
-  GlueApplication 
-  Lining 
-  CoverApplication 
Several single process: 
SpinePreparation 
Gluing 
SpineTaping 
CoverApplication 
See description above. 
PullOutValue 
PullOutValue attribute of all 
SpinePreparationParams resources, which are 
part of the AdhesiveBinding process chain. 
PullOutMake 
Not needed.   
FlexValue 
FlexValue attribute of AdhesiveBinding-
Params 
FlexMake 
Not needed.   
Page 540 
Page 540 
The following tables show how to convert the main operation and its other sub-operations.  Because new features 
were added, the CIP3 Lining operation was renamed to SpineTaping. Convert the PPF AdhesiveBinding sub-
operation Lining to a SpineTaping process. Copy the parameters of the sub-operation to the equivalent attributes 
of the SpineTapingParams resource and link them with the process. 
Table D.6  Converting the PPF AdhesiveBinding suboperation Lining 
PPF Key 
JDF Representation 
Comments 
ProcessType 
Name of the JDF process. 
TopLiningExcess 
TopExcess attribute of SpineTapingParams 
LiningExcess 
HorizontalExcess attribute of SpineTapingParams 
LiningLength 
StripLength attribute of SpineTapingParams 
LiningMaterial 
StripMaterial attribute of SpineTapingParams 
LiningBrand 
StripBrand attribute of SpineTapingParams 
Table D.7  Converting the PPF AdhesiveBinding suboperation CoverApplication 
PPF Key 
JDF Representation 
Comments 
ProcessType 
There is an extra element for each type of 
AdhesiveBinding suboperation. 
CoverOffset 
CoverOffset attribute of 
CoverApplication 
ScoringOffsets and 
ScoringSide 
Several Score elements inside of 
CoverApplication 
The Score element is much more structured than 
these two single entries. 
D.2.10 Trimming 
Convert the entries of CIP3ProductParams structure directly to the TrimmingParams resource.  Add this resource 
as an input resource link to the originated Trimming process.  See Section 6.6.46.9  Trimming for more information. 
D.2.11 GluingIn 
Because extended features have been added, the PPF GluingIn operation was renamed to the Inserting process.  
Consequently,  the parameters  of this CIP3 operation are transformed into the InsertingParams resource.   For 
more information see Section 7.2.79  InsertingParams
Table D.8  Converting the PPF GluingIn operation to JDF 
PPF Key 
JDF Representation 
Comments 
SheetOffset 
SheetOffset attribute of 
InsertingParams 
Location attribute of InsertingParams  Must be Front 
GlueLines 
Several GlueLine elements in 
InsertingParams 
See Section 7.2.79  InsertingParams for information 
on how to convert the GlueLine structure. 
Sample 
Comment of the corresponding 
Component 
Converted to an input Component of Type 
PartialProduct 
Most  of  the entries of the PPF GlueLine  structure can be  directly  mapped  to  the  GlueLine element.  Note that  the 
GluingPattern attribute cannot have an empty array to describe a solid glue line.  For this purpose, use an array of “1 0”. 
Page 541 
Page 541 
D.2.12 Folding 
Like all formats, JDF follows a structured approach in the description of the folding process.  That is why every 
suboperation has its own element type and has no need of the function entry.  Normally, the names of the CIP3 fold 
functions was taken for the name of the respective corresponding process names.  One of the specialized processes: 
•  Folding, 
•  Creasing 
•  Cutting, 
•  Perforating 
•  Gluing. 
is created for each folding sub-operation.   
Because of inherent naming obscurities, the CIP3 functions Groove and Lime were renamed to Crease and Gluing 
in JDF.  The following tables give advice on how to convert the PPF structures to JDF elements. 
Table D.9  Converting the PPF Folding operation to JDF 
PPF Key 
JDF Representation 
Comments 
CIP3FoldDescription  - 
If required, it can be expressed by the 
FoldCatalog attribute or by the fold operations. 
CIP3FoldSheetIn 
In CIP3 the parameters of the folding procedure 
will be scaled, if the value of the 
CIP3FoldSheetIn array is different from the 
dimension of the input component. In JDF a 
scaling mechanism is not supported. 
CIP3FoldProc 
-  Fold 
-  Lime 
-  Cut 
-  Groove 
-  Perforate 
Several processes  
Folding 
Gluing 
Cutting 
Creasing 
Perforating 
See previous description 
The PPF Folding suboperation is translated to a Folding process. The parameters of the PPF command are copied 
into a Fold element inside the FoldingParams resource. The table below shows how to assign the parameters of 
the PPF Fold command to the equivalent attributes inside the Fold element. 
Table D.10  Converting the PPF Folding suboperation of type Fold 
PPF Key 
JDF Representation 
Comments 
travel 
Travel attribute of Fold 
from 
From attribute of Fold 
to 
To attribute of Fold 
function 
For every lime operation, a Gluing process is generated. Create a GluingParams resource and add a Glue 
element. Insert the value of the working-direction attribute into the WorkingDirection attribute. Attach a 
GlueApplication element. To this element add a GlueLine element. The attributes start-position and working-path 
can put into the equivalent attributes StartPosition and WorkingPath inside the GlueLine. 
Page 542 
Page 542 
Table D.11  Converting the PPF Folding suboperation of type Lime 
PPF Key 
JDF Representation 
Comments 
start-position 
StartPosition attribute of the 
GlueLine element of the Gluing 
element 
JDF uses the GlueLine element because of the 
advantage of more optional attributes of this type 
of element. 
working-path 
WorkingPath attribute of the 
GlueLine element of the Gluing 
element 
JDF uses the GlueLine element because of the 
advantage of more optional attributes of this type 
of element. 
working-direction 
WorkingDirection attribute of the 
Gluing element 
function 
The remaining operation types can converted to one of the following processes:  
 Cutting. Create a CuttingParams resource and link it to the process. Transfer the parameters of the PPF 
Cut command into equivalent attributes of a Cut element and insert this into the CuttingParams 
resource. 
 Creasing. The same as above except that there is a CreasingParams resource with a Crease element 
inside which will fill with the converted parameters of the PPF Groove command. 
 Perforate. The same as above except that there is a PerforatingParams resource with a Perforate 
element inside which will fill with the converted parameters of the PPF Perforate command. 
Table D.12  Converting the PPF Folding suboperation of all other types 
PPF Key 
JDF Representation 
Comments 
start-position 
StartPosition attribute of the 
respective Cut / Crease / Perforate 
element 
working-path 
WorkingPath attribute of the 
respective Cut / Crease / Perforate 
element 
working-direction 
WorkingDirection attribute of the 
respective Cut / Crease / Perforate 
element 
function 
There is an extra element for each type of a 
Folding suboperation.  The extra elements are: 
Cut, Crease, and Perforate 
D.3  PPF Sheet Structure 
The conversion of the PPF sheet structures is much more complex than the conversion of the product operations.  A 
JDF layout structure, which is not directly specified in PPF, must be built up in order to place the mark objects such 
as register mark or density measuring field.  All other sheet information is stored in specialized resources.  These 
resources are often partitionable to specify the sheet, surface and separation to which they belong (see Section 3.9.2 
Description  of Partitionable Resources).  The result is an inheritance of attributes comparable to the inheritance 
process in CIP3. 
To build  the layout  structure, create a Layout resource that includes one Signature element with  a unique 
Name.  For each PPF Sheet, add one Sheet resource to the Signature.  Set the Name of the corresponding Sheet 
to  the value  of  CIP3AdmSheetName.   For  each  surface  (front or back)  initiate  a Surface  resource  with  one 
PlacedObjects  element.    In  order  to  define  a  mark  object,  i.e.,  CutMark,  CIELABMeasuringField, 
DensityMeasuringField,  ColorControlStrip,  or  RegisterMark,  build  a  MarkObject  element  inside 
PlacedObjects.  In that element, define CTM and an appropriate LayoutElement.  The CIP3 information is added 
to  the MarkObject by  including  the mark-specific  element,  e.g.,  RegisterMark for a  register mark.  Note: The 
Documents you may be interested
Documents you may be interested