Jump to content

VPS RIPping very slow compared to XMPie version


Duake

Recommended Posts

I was wondering if anyone could explain why a VPS file would RIP slower being made in FusionPro Desktop than one made from XMPie.

 

My assumption is because FusionPro runs in Acrobat and XMPie runs in InDesign. PDFs usually don't like to RIP very fast in my experience. Our previous HP RIP with 8 blades took FOREVER to RIP PDFs. The current RIP is a CREO Spire.

 

Since the VPS is being created from a PDF, is that the reason why it would RIP so slow? After an hour of trying to RIP 4000 records, it was only 13% done. The XMPie version only took 10 minutes. This is definitely a problem with our business if we can't get faster RIP times through the Spire.

 

Any and ALL help is appreciated!

 

David

Link to comment
Share on other sites

Found an archived message about the VPS being slow on the CREO. Going to try the Multiple VPS output to see if that speeds up the RIP time. I'll post what happens when it's done.

 

David

Link to comment
Share on other sites

Don't confuse FP Desktop's architecture as a plug-in to Adobe Acrobat with the composed output that it generates. The fact that FusionPro Desktop is a plug-in to Acrobat and uses PDF files for templates doesn't mean that its VPS output is somehow less valid than any other VPS file, or is "PDF-ified" in some way. You could compose with FP Server and get the same output, without involving Acrobat, and even without using PDF background pages.

 

I would expect that your RIP times would be somewhat better using multi-file VPS instead of single-file, especially if the graphics are external to the job and can be pre-loaded onto the RIP. I would also try using PPML, which has even more optimization options.

Link to comment
Share on other sites

The RIP actually didn't like the PPML ZIP file that was created when I output that type. Not really sure why.

 

As far as the VPS is concerned... Any theories on why the VPSs from two different VD programs would be that different in time in RIPing? Have you guys experienced any slowdown in different RIPs or have a thread about what file types would be better for certain RIPs?

Link to comment
Share on other sites

The RIP actually didn't like the PPML ZIP file that was created when I output that type. Not really sure why.

I'm not sure why either. If you could provide more specific information about exactly what the failure mode was, then someone might be able to analyze it. You may need to work with Support.

As far as the VPS is concerned... Any theories on why the VPSs from two different VD programs would be that different in time in RIPing?

That's kind of like asking why Microsoft and Apple products work differently. The technologies are different, and proprietary. We don't get to see other vendors' composition algorithms, and they don't get to see ours. All we can do is try to optimize our own compositions and our output for various RIPs.

Have you guys experienced any slowdown in different RIPs or have a thread about what file types would be better for certain RIPs?

http://forums.printable.com/showpost.php?p=1443&postcount=2

Link to comment
Share on other sites

Just got an e-mail from my Press guy and he said after 18 minutes it was only done with 3% of the Multi-file VPS.

 

Not really sure why the RIP is not really liking the VPS that I'm making, but flies with the XMPie one. We can't have the files going this slow as they'll be slow for all of our future clients using the Spire RIP.

 

Going back to the InDesign aspect, I used HP's SmartStream Designer to create JLYT files and the HP RIP processed 5000 records in 4 minutes. It didn't like PDF files very much either. The coincidental thing is that we had a company do our VD mailers and they used FusionPro to make the PDFs. Using 1 blade, it took about 3 hours to RIP 1100 pages. Granted those were PDFs, but the VPSs I'm making to RIP seem to take about that long on the Spire.

 

I'm just trying to understand why the RIP takes so long to process it's native file type using FP Desktop. Are there certain issues perhaps with specific versions of Spire RIPs or any other RIP for that matter? Just curious as I need to fix this slowdown issue ASAP.

Link to comment
Share on other sites

The job I'm running is 37,000 pieces. The prepress department has a trial for XMPie and it doesn't have an issue doing 4000 records at a time and then RIPing on the Spire. The files I make RIP on the Spire, but just REALLY slow, no matter what file type I use.
Link to comment
Share on other sites

We had problems with ripping the composed PDF files with our Spire too. We talked to a CREO tech. This is what we found out.

 

FusionPro makes PDFs that are already optimized. The problem was that we were "printing" them from a separate machine, not ripping them on the Spire. So basically it was ripping all the common graphics that are in each record each time. So in your job it was ripping the same common elements 37,000 times. Not sure if your Spire is the same model (CXP5000) but here is the process we use now and it goes MUCH faster.

 

Go under File in the menu bar at top and select Import Job. Select the job from wherever you have it saved on your server and click the green arrow (or whatever it is on your spire) to add it and then choose Virtual Printer: XRXCXP5000_SpoolStore and then click import. This imports the file into storage without doing anything to it. Bring up the Job Settings window for the job you just added to storage and set it up the way you usually do for output. Here is the important part, in those settings go to the Services Tab. At the bottom of the list is PDF Optimization. Set that to YES. You are telling the rip that the PDF is optimized and only rip the common stuff once.

 

I'm not sure if it will work the same for VPS but this was our solution for the PDF. Hope it helps.

Link to comment
Share on other sites

Thanks for the reply, Brian.

 

Using PDFs, do you happen to have a time on how long they took (say 100 pieces) to RIP using the method you described? If it goes faster than the VPS and comes out without a hitch, then we might go that way.

Link to comment
Share on other sites

The old way we were doing it, it took about 20 minutes to get 50 pages of a PDF ripped. It was laid out 4 records up on a 12.5x19 sheet. We were splitting jobs up into 50 page batches just to keep it moving.

 

I just did a time study for you with the new method. A 168 page PDF laid out the same way took 2 minutes 40 seconds to rip it completely.

Link to comment
Share on other sites

The way ours it set up is 2 8.5x11 sheets, duplex on 12x19 sheet. Basically, I have 2 records per sheet. We're going to do a test with the PDF in a 4000 record batch, since we do them in lifts for cutting, and see what we get and I'll post the time here.

 

Thanks again for the test, Brian.

Link to comment
Share on other sites

Looks like the PDF trick worked flawlessly! Thanks for the tip, Brian.

 

The RIP only took about 10 minutes to process the 4000 records.

 

I've experienced the PDF optimization issue with the Spire before. Checking it worked wonders.. FWIW, we could never get VPS to work on it either. There was also a patch for the PS optimization at one time, but, may be included in the later rips now anyway..

 

For the HP multi blade rips, PPML flies, JLYT is fastest, but, the format has a lot of issues with anything that resembles transparency.. If ou can get these PDF's flat, it flies.. It is especially good when just swapping data out..

 

Mark

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...