Pdf secure signature application control tool html azure wpf online JDF_1.2.TBD.030926-WORD9-th-color-03100656-part402

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

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

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

• 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

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

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

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

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

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

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

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

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

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