pitstop server - only for simple environments?

[lfelton]

Still evaluating Pitstop Server...

Is the hot folder concept only designed for an environment where you are printing a simple range of products?

For example, if I want to check that the supplied file has specific dimensions, I can't pass this data to Pitstop Server in any way at all. I've got to set up different hot folders for products with different dimensions and write an action list for that hot folder. Likewise I can't tell Pitstop Server the target CMYK profile, or the TAC, so have to create still more hotfolders, and so on.

It will be pretty straightforward to write a (shell) script to read the job information that we have associated with a specific PDF and so drop it into the right hot folder input folder, so that shouldn't be a problem. But we're left with a *lot* of hot folders and action lists to manage.

Am I looking at this the wrong way?

Is Pitstop Server only really designed for "part" checking a PDF, i.e. in reality most users will do more manual checks before manually passing the file on for further processing & scheduling? If so, what "automateable" preflight server product should I be looking at to in a multi-vendor, mixed digital/litho/large format environment?

 

[the_brain]

Still evaluating Pitstop Server...

Is the hot folder concept only designed for an environment where you are printing a simple range of products?

For example, if I want to check that the supplied file has specific dimensions, I can't pass this data to Pitstop Server in any way at all. I've got to set up different hot folders for products with different dimensions and write an action list for that hot folder. Likewise I can't tell Pitstop Server the target CMYK profile, or the TAC, so have to create still more hotfolders, and so on.

It will be pretty straightforward to write a (shell) script to read the job information that we have associated with a specific PDF and so drop it into the right hot folder input folder, so that shouldn't be a problem. But we're left with a *lot* of hot folders and action lists to manage.

Am I looking at this the wrong way?

Is Pitstop Server only really designed for "part" checking a PDF, i.e. in reality most users will do more manual checks before manually passing the file on for further processing & scheduling? If so, what "automateable" preflight server product should I be looking at to in a multi-vendor, mixed digital/litho/large format environment?

Ifelton,

There is another product from Enfocus called Switch that can handle the task you mention. Because it's an Enfocus product the PitStop Server intergration is almost 100% which means you have loads of options.
Basically it's product that allows you to script, in the bigger sense of the word, using a nice UI.
Check www.enfocus.com for more info.

You have different flavors (Light, Full and Power). Lowest price = less than 1000 USD.

Next to PitStop Server it intergrates with a number of third party software such as Adobe CS, Alwan, Elpical, Callas, etc.
You find more info about it at www.crossroadsworld.com

This allows you to tackle native files and do advanced PDF processing...

Cheers,
Bert

 

[mattbeals]

When using SWITCH you can dynamically choose which preflight profile to use for PitStop Serve or Callas pdfToolbox based on metadata in the job. Of course you have to have the information about the desired size and other parameters first. Then once you have that you can designate the appropriate preflight parameters. With Callas pdfToolbox Server and SDK you can call a specific profile directly depending on how you integrate pdfToolbox.

Usually though you have to create a series of cascading preflight profiles to either first sort based on size (pass/fail) or on color first. Then you create branches off of those for the other parameters. It gets to be a real mess real quickly. If you can call the preflight parameters directly obviously it is more efficient but takes longer to program around. How are you trying to implement this process?