Printing solid images to a DocuColor

[JoshB]

Does anyone have experience trying to print fully-variable images to a DocuColor at rated speed? I need to print full-sheet images to a DocuColor 5000AP with FreeFlow server and not have the machine bog down. Currently, it print at about 1/5 rated speed. Again, these are fully variable images, each is different from the last.

So far I've tried resampling the images to 600dpi Tiff (the 5000AP has a hardware dpi of 2400, but uses that to produce an output image of 600dpi with varying values). I've wrapped the 600dpi image in PDF and in PostScript.

Not sure where to head from here. It's very frustrating that the controller spends so much time trying to "rasterize" my already rasterized file. Xerox support is completely useless on this. They are great at fixing things that are "broken", but that's all they can help with. Support requests like this get supposedly kicked "Up the chain" and then are never heard from again.

 

[jotterpinky]

I think with that particular print engine you are overkill for much of anything over 300 ppi on the images. If it's variable as you mentioned I might even be tempted to fudge it to 250ppi to speed up processing.

You might try some tests with different resolutions and see how the graphics are affected by the lower resolutions before you commit to something smaller.

 

[jotterpinky]

I almost forgot to mention that you'll also want to save as jpegs as they are smaller in file size and will be read into the RIP much faster resulting in faster processing.

 

[X33]

1. you should use images at 300dpi ... any higher resolution will slow down the process and you will not notice the difference when printed.

2. what is your output file to the FreeFlow server? PS, PPML, VIPP, etc?

3. what sw are you using to create your VDP file?

4. how many images you have in a run?

 

[DigiPrint]

If the engine is slowing down, it should not be a limitation of the printer but the rip. Are you having the server process and hold the job, or doing a direct print? By processing and holding at the RIP you should be allowed to release the processed job for print directly and should have no slow down.

 

[JoshB]

X33 --

1. The difference between 600 and 300dpi is very obvious and detrimental, unfortunately. Already had tried this. There is a lot of text and vector art mixed in with photos, and the text especially suffers.

2. I've tried PS and PDF, doesn't seem to make a difference.

3. When I say variable, I don't mean in the VDP sense of "We're switching out a customer's name on a postcard." I mean in the sense that this is a print on demand product, and each piece coming down the pipe can be completely different from the last. I should have clarified that.

4. Potentially it's a run size of "1". We of course get larger sets, but "1" is very common.

---------------------------------------------------------

Jotterpinky -- JPEGS didn't seem to be too different from TIFFs, speedwise. I'd also like to avoid any tiling artifacts.

----------------------------------------------------------

Digiprint -- This is a definite possibility. We're on direct print now. I'd like to keep manual intervention as limited as possible, so I want to avoid making an operator release queues if possible. This is a potential way to solve things though if it comes down to it, we can task the machine with longer run jobs, letting the RIP catch up on the held queue, and then release when ready.

 

[JoshB]

I guess what I'm hoping for is that you can send 2400x2400 CMYK (1-bit per channel) images that are ready to be directly imaged on the drum. So far I haven't had any success with that, however. I was hoping to find someone who had already found the magic formula.

 

[killer1loop]

Unfortunately the FreeFlow print server is not so quick in unpacking PDFs, because of the process of unpacking to PS and then repackaging to PDF before print. You should avoid sending small batches so, you can speed up packaging many pictures into one PS or EPS file, because you avoid many file opening and closing.

Then talking about the engine, you should go into administration panel on the machine itself and choose not to cycle down on every job you send. DC5000 is slow in calibrating, so you should avoid that operation as much as possible (which is still done not sending small batches but larger ones)

 

[JoshB]

Thanks, killer. I'll give that a try.

 

[thebluesdude]

Why would you be trying to print in 2400 dpi? what are the source files for that dpi.
We have been using a DC5000 alongside other machines for about three years now and I have to say even when playing around with machine dpi, custom screens and stochastic screens, I dont think anyting will really make the machine perform as well as your looking for.
I guess the smooth inkjet look is a few years off with xerographic engines at the moment. Speed wise I agree with the guys, you need to be holding common files pre ripped and just flashing in anything thats changed. I have also had some good experience in using variable data with hot folders?

Hope you find what your looking for
Ron

 

[JoshB]

Well, it's just a thought, but since the machine is 2400 hardware dpi, it seems like I should be able to send 2400dpi CMYK images with 1-bit per channel, and avoid the RIP altogether since that is essentially what the rip has to create in the end anyway.

I'm looking for a way to do the hard work up-front and off-line and just pass through the RIP to avoid that bottleneck.

 

[mattbeals]

Josh, are you saying that you have a rasterized page where are the text and graphic elements are raster image?

 

[JoshB]

Yes, Matt. I have full sheet PDFs. You open the PDF and there is a single element in it -- an edge to edge image containing everything on that page. That's my mission. Get that to print at speed through a DocuColor with FreeFlow.

 

[mattbeals]

When submitting a PDF to a RIP where the PDF is compressed the data has to be decompressed. 8.5 x 11 at 300 dpi is about 32MB, at 600 dpi it's 128MB for a rasterized page. No wonder you're seeing a performance hit and quality issues as you drop the resolution.

You really should be printing the images at no higher than 300DPI. All non-image objects should stay as vector objects so that they image at the highest possible resolution. I really do not think it possible for you to feed the printer a screened 1-bit TIFF per channel. Best bet, cache everything you can, keep vector objects vector and keep raster images as raster images.

 

[kandod]

JoshB use acrobat and its preflight/optimize function or even better if you have a third party plugin like PitStop, avoid making complex object/image areas especially with transparencies in it that take a lot of processing to flatten, use no more than 300ppi for images, and btw CMYK image in 1 bit/channel could only print Cyan, Mag, Y, K, CM, CY, YM, CMY, CK, etc. and printing a true color image with that color depth would require about 16 mil color channels printer.

 

[mattbeals]

Kandod, it would not take a 16 million color printer. It happens all the time with printing presses just this very way... The screened 1-bit TIFF's when combined (one for each color) will yield a composite CMYK image. Even if they were contone "bands" they would combine. Just like the channels in PhotoShop. The optimize PDF functions in Acrobat Pro would work for downsampling, flattening and general optimizations as well as PitStop. Except for the fact that PitStop can't flatten transparency.

 

[jotterpinky]

I believe I understand what you're after: you want a file that has already been rasterized in the same format the printer consumes so when sending the file it goes straight through the RIP (as if it's been processed already since it's the native format). I don't believe this is something that's possible unless you are able to get information from Xerox about what file the printer itself (not the RIP) consumes. It seems to me what you're doing is trying to build a third party RIP - similar to sending a 1 bit black/white image to a Harlequin or similar RIP.

The reason why I don't think this is possible is Xerox will never release their print engine technology to someone like yourself. You would basically be competing with their RIP manufacturers (EFI, CREO, etc). since you would essentially be ripping the file prior to sending it to the printer. I'm no expert but it seems that there would be a number of issues with sending the raw data such as screen angles, color management etc.

 

[Raster]

Well, it's just a thought, but since the machine is 2400 hardware dpi, it seems like I should be able to send 2400dpi CMYK images with 1-bit per channel, and avoid the RIP altogether since that is essentially what the rip has to create in the end anyway.

I'm looking for a way to do the hard work up-front and off-line and just pass through the RIP to avoid that bottleneck.

You would have to get Postscript/PDF to write instructions to the hardware. It will not happen. That is the purpose of the RIP. To translate a PDL (whether it be PCL or Postscript/PDF) to hardware instructions. What you are asking to do is sit in the back seat and drive to Montana.

 

[X33]

Yes, Matt. I have full sheet PDFs. You open the PDF and there is a single element in it -- an edge to edge image containing everything on that page. That's my mission. Get that to print at speed through a DocuColor with FreeFlow.

Not possible. That's what the RIP is for. Translate your files into something that the printer can understand.

I think you are sending the files in a wrong way. One image per PDF file is not productive. The RIP is taking a lot of time opening each file, ripping it and then going to the next.

One option would be to put multiple images in one PDF. You can try to see how that works.I would also try a PROCESS AND HOLD before printing.

 

[UberTech]

X33 is right, the RIP converts the data to what the engine understands. You can send a 2400 dpi image to the machine if you like, it's going to down sample it anyway, which is going to take time.

I don't know much about freeflow but a quick glance at the webpage says it supports PPML and other VD types. Also Ahem, I quote "Outstanding variable data capabilities let you efficiently compose complex VI jobs with sophisticated formats and graphic elements".

If this is indeed a variable data job then you must have multiple common elements otherwise your just printing lots of complex jobs. There must be somewhere on the rip you can store pre rasterised versions of these common elements.