Impoproof input

[kyle]

What input methods are available for the Impoproof system? We're considering getting one, and I'm hoping they can receive either PDF or Postscript files (or Postscript via a Windows printer) from our Printdrive server.

 

[DCurry]

We feed ours unscreened tiffs generated by our rip.

Be careful sending it PDF or postscript - then you're using a different rip from whatever makes your plates so you may get different results. By making your rip generate the tiffs for both the proofer and the platemaker you won't get nasty surprises.

 

[kyle]

The PDF or postscript from our Printdrive server is actually safer than if it was generated by the RIP, because it receives the 1-bit images that will be used to make the plates from the RIP, and creates both the proofs and the plates from those same images (i.e., "RIP once print many"). That's actually a lot safer that using the same RIP to process the same job twice for separate output devices.

We can output TIFF files (that's what our platesetter eats), which would have to be 2400 ppi 1-bit images. Are you feeding your Impoproof full-resolution 8-bit images, or are they at the resolution of the proofing device? I asked about PDF/PS input because Printdrive can output 8-bit descreened and down-sampled images at arbitrary resolutions for proofing (just not as TIFF files).

 

[tigersticks]

We send 300 dpi CMYK composite images from Printdrive to our ImpoProof front end in PostScript form. We only use this occasionally. Primarily we have the RIP generate the Composite Proof in the same workflow that creates our 1-bit TIFF data for plating.

 

[DCurry]

The PDF or postscript from our Printdrive server is actually safer than if it was generated by the RIP, because it receives the 1-bit images that will be used to make the plates from the RIP, and creates both the proofs and the plates from those same images (i.e., "RIP once print many"). That's actually a lot safer that using the same RIP to process the same job twice for separate output devices.

OK - I was thinking you were feeding your PDF to your rip and also feeding it to your proofer's rip, which is where problems could arise. Since you're not doing that you shouldn't get any surprises.

Are you feeding your Impoproof full-resolution 8-bit images, or are they at the resolution of the proofing device?

Within one workflow, my rip (Nexus) generates a 450-dpi unscreened (8-bit) TIFF for the proofer, and also generates 2400-dpi 1-bit TIFFs for the platesetter. Perfectly safe because the same settings are applied to the file within the workflow. Most workflows I've used work this way.

 

[kyle]

tigersticks:

If you only send from Printdrive occasionally, what are the advantages to sending from your RIP? I find having Printdrive produce proofs frees up the RIP to get raster data to Printdrive faster, and gives me perfect confidence that the proof will match the press sheet exactly.


DCurry:

Do you know if sending the 2400 ppi 1-bit images would work?

 

[tigersticks]

tigersticks:

If you only send from Printdrive occasionally, what are the advantages to sending from your RIP? I find having Printdrive produce proofs frees up the RIP to get raster data to Printdrive faster, and gives me perfect confidence that the proof will match the press sheet exactly.

The main advantage is speed. Our Nexus RIP creates the proof file and plate data in the same workflow. Proofs come out and the plates are ready for imaging from the Printdrive. If we wanted to print proofs from Printdrive it would be a two part process, take longer, and at least for us, a manual decision to output the proof. We have used this setup for years and not once has there been an issue where the plates and proof don't match. We only use the Printdrive to output proofs when another blueline is needed and the job is no longer in the Nexus workflow. We also have two Nexus RIPS. One for impositioning/raster data and the other for RIP/Trap of pages.

 

[DCurry]

DCurry:

Do you know if sending the 2400 ppi 1-bit images would work?

No, I don't know. I'd try it out, but I don't run the proofer and the guy who does doesn't like to "experiment." I would think you'd need a way to merge them together so you could proof in color.

As mentioned, all the systems I've used before proofed from 8-bit unscreened.

 

[kyle]

Thank you both for the information!

 

[rich apollo]

The ImpoProof will accept data directly from PrintDrive. kyle, are you trying to generate contract proofs from PrintDrive and an ImpoProof?

 

[kyle]

Rich,

Presently, our color proofs are printing from Printdrive to Epson 9800s, which Printdrive has a specific device type for (it sends data directly to the Epsons along TCP port 9100 using EJL language). Our content/position proofs are printed to HP Designjet 1050s similarly.

We're considering switching from HPs to Impoproof to make the content/position proofs, but there are no Canon device types. Printdrive can, however, output PDFs and Postscript data for proofing, and I'm hoping that method would interface well with the Impoproof software.