Created Date: Dec 01, 2020 15:09
Last Modifed Date: Jun 24, 2021 13:58


A Mako input class, IIJPDSInput() is available in Mako 5.2.2 and later. Designed to convert to KODAK VERSAMARK IJPDS formats to PDF, it enables content in this format to be “recovered” into a form that can be easily shared or reprinted.

The document format enumerator is eFFIJPDS, so the input class can be instantiated with IIJPDS::create(jawsMako) or IInput::create(jawsMako, eFFIJPDS).

Several input parameters are available to control how the IJPDS content is assembled into the PDF. These collation options are needed because IJPDS is essentially a sequence of bitmap pages, the order of which is arbitrary and determined at file creation. For example, they may be separate monochrome pages or each a color separation for a page. Although pages are assigned to a logical RIP (raster image processor) for physical printing, IJPDS doesn't directly specify how the different RIPs are to be interpreted. During testing, we encountered:

  • A job with eight RIPs, which should be interpreted as CMYK separations for the front and back of a (duplex) page
  • A job with eight RIPs that are all individual mono pages

The collator works by treating all pages assigned the same logical RIP in the same way. The table below lists these options:

Setting the input parameter

IIJPDSInputPtr input = IIJPDS::create(jawsMako);
input->setParameter("ripsetup", "cmyk");
CPP
IIJPDSInput input = IIJPDS.create(jawsMako);
input.setParameter("ripsetup", "cmyk");
C#

Permitted parameters

Parameter

Possible values

Description

ripsetup

mono

Default. Each RIP generates its own page.

cmykGroups RIPs together in blocks of four to generate a composite page.

ripinterleave**

true (or 1)

Default. Output is ordered in page number major order. All the first pages from each RIP are output followed by the second pages, and so on.

false (or 0)Output is ordered by RIP major order. All the pages for RIP 1 are output followed by all the pages for RIP 2, and so on.
riporder*



fromjob

RIPs are arranged in the order the job defines them. Default.

ordinal

RIPs are arranged sequentially in their ordinal numbering (starting from 0,for example, Rip0, Rip1, Rip2, Rip3...

0,1,2,3

A comma-separated sequence of RIP IDs (a number from 0 to 15, or -1 if a blank is desired for that slot. This controls the sequence in which the RIPs are processed. By default, the order in which the RIP is defined by the job is followed.

0,1,3,2

Example: For CMYK output it is sometimes necessary to change the plate order (here 0,1,3,2 is specified) to obtain the correct composite output.

-1,2,-1,-1

Example: If -1 is encountered in CMYK output, then that separation is interpreted as a blank. This is useful to see a separation in a specific color. For example, specifying -1,2,-1,-1 uses the page from RIP 2 as the magenta plane with all other color planes blank. This results in a CMYK composite output where only RIP 2 comes out in a magenta color. For non-composite output -1 is ignored as it does not make sense to output a blank page.

collation*

bypage

Default. Output is ordered in page number major order. All the first pages from each RIP are output followed by the second pages, and so on.


byripOutput is ordered by RIP major order. All the pages for RIP 1 are output followed by all the pages for RIP 2, and so on.
riprotate*


0

This denotes the rotation of a RIP separation in the output page.

The value is an angle in degrees, counter-clockwise.

Possible values are 0, 90, 180, and 270; the default value is 0.

90
180
270
stitch*true (or 1)

Individual RIP separations are combined into one page by stitching them together. Default.

The orientation of the stitching can be controlled by the stitchhorizontal parameter.

false (or 0)Individual RIP separations are each output as separate pages.
stitchhorizontal*true (or 1)The RIP separations are stitched in a horizontal orientation.

false (or 0)The RIP separations are stitched in a vertical orientation. Default.

resourcedirectory

<path to resources folder>

Sets the directory where remote resources are located (that is, resources referenced by the IJPDS but external to it).

 * new or updated in Mako 6.1.1

 ** removed from Mako 6.1.1 (and later)