I need to be able to calculate the imposition value in Switch after any step and repeat imposition.
This needs to be factored in when sending print quantities to the press.
We currently use QuiteImposing for this, which includes how many columns and rows were created during imposition on the metadata xml that it adds to the pdf. But we’re trying to move this function to Callas and so far I’ve been able to see the steps taken during a process plan, but couldn’t find anything that I could use to calculate how many times the original pdf was duplicated during imposition.
How do you do the imposition? Is it a configuration that you created?
(In other words, do you know how many times step and repeat has put the file on an imposed sheet in pdfToolbox itself?)
The imposition is Javascript based. It’s basically a generic step and repeat to impose any document to an SRA3 sheet, so it can be anything based on the document coming in.
I also have another post for an FST process plan, that one can even end up on a different sheet size (SRA3 or Banner Sheet).
But if it’s a Javascript-based imposition, your imposition configuration knows how many items per sheet you have right? I mean, something has to calculate the number of rows and columns I would think?
During a JavaScript imposition, your JavaScript can store information in app.vars:
These variables remain stored in app.vars as long as your Process Plan runs. You can then use a VarDump report or the new Create File action to expert them as a JSON for example so that you can use them in Switch.
Thank you very much for your help.
Yes. It’s a Javascript and I can use the cols and rows variable.
However, I need this information embedded on the imposed pdf (or PDFs in the case of FSTs where the cover needs to be separated). The imposed pdf goes to other flows that need this information and it’s not easy to transfer information from one file to another in Switch without adding a lot of complexity to a flow (as far as I’m aware).
I tried setting up a vardump report to embed as metadata. Although it worked, I ended up with two pdfs (the original and the imposed).
I find the report options in the pdfToolbox Switch App very confusing. They don’t behave like I would expect based on my experience with Pitstop. And the instructions online seem to be mostly for Desktop or CLI reports as opposed to how they behave when using in Switch.
Is there a reason why it’s spitting out two files (only the imposed file goes to the output folder if the report is off)? And can I change it so that only the imposed file goes out to the output folder?
You could potentially save this information in the PDF itself, but then it depends on whether this would work. Probably your main way of doing it, would be putting it in XMP in the PDF (which you could then access in Switch using variables).
Transferring information between Switch flows isn’t that difficult, as long as you retain the job ticket. Which would mean you would have to have a folder that doesn’t remove the unique ID and is used as “transfer hub”, or you would have to use one of the Switch apps to make connections like that. Used those in the past and they’re excellent!
I think setting up VarDump as you’re doing is correct, and I think you’re running into a bug we’re looking at at the moment. When it’s set as “dataset” as in your screenshot, you should actually only be getting the imposed file (with the dataset being attached behind the scenes), but I think I’ve seen a bug report that this is currently not the case, and it’s something being looked at to solve in the apps.
As for Switch in general, yes, most of the documentation doesn’t really mention Switch, and it’s something that’s on my list of changing. Keep telling us what you’re missing; that’s really helpful to know what we should focus on for the documentation and so on!
