Using "Job Ticket mode" with callas pdfToolbox Server hotfolders

pdfToolbox
1

Sharing my Experience with Imposition Using “Job Ticket Mode” in pdfToolbox Server

Hi everyone,

I wanted to share my recent experience with using the powerful imposition functionality of pdfToolbox, especially for those who are considering the Job Ticket approach for automation with Server version hotfolders.

Currently, I’m working on setting up simple digital impositions for our book production. The workflow involves printing all content pages 4 pages per print sheet, which is then gathered and processed further down the production chain.

After successfully designing a working imposition setup in desktop mode, I aimed to scale it to our server environment using a drop folder and Job Ticket integration.

However, the debugging process turned out to be quite challenging when relying solely on the product’s built-in development tools. It took me a significant amount of time to figure out:

  • Why my parameters weren’t being interpreted correctly
  • Why jobs were not being imposed, even though the Job Ticket appeared to be correctly structured

My Imposition Setup

My imposition setup expects multiple parameters, such as:

  • sheetWidth
  • sheetHeight
  • jobNumber
  • …and others

:warning: Heads-up #1: All Job Ticket Parameters Are Passed as Strings

Even if you’re expecting numeric values (like sheet dimensions), from “job ticket” they will arrive as strings inside your script.

You’ll need to explicitly convert them to Number type if they’re used in calculations or measurements.

For example:
My script used sheetWidth to define sheet size. Although I was expecting that I am passing a number, it is passed as a string, causing issues that were hard to identify as a beginner.

Internally in my imposition script I then recieve it like this, by adding “+” prefix. That converts passed string number to actual number type:

const sheetWidth = +app.vars.sheetWidth;

I assume const “sheetWidth = Number(app.vars.sheetWidth);” would also work.

:warning: Heads-up #2: Small Syntax Issue in the Documentation Example

In the Job Ticket documentation example (Callas Documentation Link), I noticed a small syntax typo that can trip people up when copy-pasting:

  • :cross_mark: Incorrect:
    —setvariable=placetext:Text for DummyPDF (note the long dash)

  • :white_check_mark: Correct:
    --setvariable=placetext:Text for DummyPDF (should be two hyphens)

image
image897×262 9.14 KB

Hopefully, this helps someone just starting out with Job Tickets and imposition, using pdfToolbox Server.

I would also like to thank the Callas support team for their assistance in properly setting up shingling, which I had been struggling with. Their support was invaluable and greatly appreciated.

That said, I’m still learning and there’s a chance I might have misunderstood or done something the wrong way — if you spot anything odd or have suggestions for improvement, I’d be happy to discuss and learn from your experience.

Cheers,
Aldis

2 Likes
2

Very good point, and yes, this is indeed the case. Anyone who is working with Switch will have likely had the same experience, variables are always passed as strings.

In most cases that isn’t an issue, but there are certainly cases where you have to do the number conversion or you end up with: 1 + 2 = 12 situations…

3

Ah, yes. This is because on macOS the auto-correct has a tendency to replace “–” by “-” when you type. Apparently we didn’t catch it in this case.

Thanks for telling us, I’ve modified it on the documentation page - it should now be correct!

1 Like
4

For the sake of completeness - even if it makes the problem more complicated if you think about it more closely.
You can ensure type safety by using --setvariable with a JSON file; like: --setvariable=myvars.json

{
	"vars" : 
	{
		"sheetWidth" : 200
	}
}
1 Like
5

And how that myvars.json file should be passed? Dropped side by side with .jobticket file inside “In” folder?

6

Here it will be complicated … it must be some pre-processing during the creation of the .jobticket where you put all parameters for the CLI call and the the JSON for the variables would be an addiotnal file which can be passed in the .jobticket (via “–etvariable=PathTo/myvars.json”) … cleanup work not included.

Maybe not ideal in this concrete situation but at least I wanted to mention the ability over a JSON to provide Variables values (and keep type safety - even if the Profile need to be prepared; Variable as Number or Number as String)

1 Like
7

Oh, now I understood. Thanks. Will try this method at some point. :folded_hands: