Nexus PDF RIP Speed Issues

[Kristian]

We have recently added the PDF RIP option. Although it is working correctly we have noticed that it can be really slow on some jobs compared to using PostScript and Link Files. Does anyone have any tips that could help speed things up.

PDF workflow:
Linework ArtPro file exported to PDF
Imposed and PDF generated of complete imposition (138 up)
This took 55 minutes to RIP!

PostScript Workflow
Linework ArtPro file, create PostScript and make Link File
Impose and postscript imposition.
Entire job RIP'd in under 11 minutes.


Am going to look at trying different options in the PDF and different compression types to see if that makes any change but thought I would ask on here first. Any ideas are appreciated as at busy times this is going to get very frustrating. Don't want to have to use PDF RIP for some jobs and Postscript for others. Would like to fully move over to PDF now we've paid for the upgrade.

 

[GinSu]

Re: Nexus PDF RIP Speed Issues

I haven't made the move to a PDF workflow yet for this very reason. In a pure PDF workflow, the PDF has to be processed again at every step. With the PS/Link workflow, once the PS is processed the work is done.

I'm sure there are details I don't know about, but I take comfort that my EskoArtworks sales rep agrees that pure PDF is still not quite there yet, at least for our hyper quick turnarounds.

 

[Joe]

Re: Nexus PDF RIP Speed Issues

I know it's slower but I haven't seen that much of a slowdown. How much memory do you have in your Nexus box? How many instances of TotalRIP are you running on that box? We have 4 GB of RAM on our Windows 2003 server Nexus box. We have 4 instances of the assembler running on our PS workflow so I think if we were to change over to the PDF workflow I'd kill 3 of them and run at least 2 and maybe 4 instances of the TotalRIP (if possible, haven't checked yet). Also, I was told by Long to use packbits compression. One other thing I've found is it's MUCH slower if you outline the text and then have it trapped. Once it gets to the multi-up impo it takes forever to process. It speeds it up considerably if I leave the type live all the way through the process.

We're still just in the testing stage at this time though we're going to have to go to it soon. I understand EskoArtworks it putting no more development in the postscript Nexus RIP side of things. All development/research is being done on the PDF side.

 

[Kristian]

Re: Nexus PDF RIP Speed Issues

Thanks for replies.

Joe, we are running the same setup as you. WIndows 2003 with 4Gb RAM. We currently have 4 assemblers (2 for screened TIF's, 1 for LinkFiles and 1 for Epson Proofs). RAM was split between each assembler, obviously much more assigned to the Screen TIF assemblers, you do not have the option to adjust memory usage for the Total RIP Module.

Most files do tend to rip fairly quickly, it seems to be jobs with either extremely large files or small files stepped up over 100 times that cause huge slow down. All our files are in ArtPro and have already had text converted to outlines, trapping has already been carried out in the ArtPro file so the PDF is just being rasterised.

We are currently already using Packbit compression.

Thanks for your responses.

 

[Joe]

Re: Nexus PDF RIP Speed Issues

I'm wondering what benefit you are getting from the PDF RIP if all of the processing is carried out in Artpro and you are just using the Total RIP for screening rasterized data. It seems all you have done is slow the process with no obvious benefit unless I'm missing something here. I think the main benefits of the Total RIP is the upfront processes such as Pitstop preflight, color remapping, and trapping...all while retaining live transparency right up to the point of screening.

 

[Kristian]

Re: Nexus PDF RIP Speed Issues

Some jobs do not import into ArtPro very well due to having loads of transparencies used. So now we can at least keep these in Illustrator format and go straight to PDF.

But yes, most jobs will be in ArtPro format and already be trapped. Most jobs will still have transparencies in them which we felt would go through a PDF better than using postscript as pDF seems to be the way to go. Not really convinced at the moment though.

 

[Bobmorli]

Re: Nexus PDF RIP Speed Issues

As Joe says, it is a known issue that the PDF nexus rip is really slow compared to the PS rip. I was told this would be better in nexus 9.

I've also noticed that jobs (mostly) illustrator with a lot of tansparencies (and other Appearence settings) tend to give us problems in Artpro.

Anyhow, if you are using nexus, i'd stick with PS for the time being...

 

[ArtproPro]

Re: Nexus PDF RIP Speed Issues

My suggestion would be to upgrade your Nexus box. We are running Nexus 8.6 on a dual quad core Windows Server 2003 enterprise edition with 12 gb of RAM 10,000 rpm drives. The speed of the PDF rip is incredible. It's at least 4 times faster than our PS rip. The issue that we do come across is that it does not handle transparencies very well. When it comes across PDF files with transparencies it takes up a lot of RAM. It would be interesting to look at your problem file and see if I could troubleshoot it.

 

[Kristian]

Re: Nexus PDF RIP Speed Issues

> {quote:title=ArtproPro wrote:}{quote}
> The issue that we do come across is that it does not handle transparencies very well. When it comes across PDF files with transparencies it takes up a lot of RAM.


I thought transparencies were the reason to upgrade to the PDF RIP? Are you saying its still best to flatten PDF's before sending through?

 

[Joe]

Re: Nexus PDF RIP Speed Issues

The Nexus software is not 64 bit though is it? I realize it will allow the OS to see the ram over 4 gb but doesn't the Nexus software have to run under some type of 32 bit emulation with this setup?

And I don't get what the point of the PDF RIP is if it bogs down with transparency. That is what it was built to handle.

 

[PrepressDan]

Re: Nexus PDF RIP Speed Issues

Joe, there are very good reasons for going to the PDF rip if you are using a artpro workflow. That reason is to maintain transparencies. If you have the Nexus CTLW rip that you are sending it a postscript. If you have the PDF rip you can send it a PDF 1.7 and the data will never be flattened. The rip was designed to RIP as it reads without flattening first. While the actual rip speed may be slower it is because it is dealing with alot more complicated file structure than a postscript rip. We switched our Nexus to a Mac with 16 gigs of ram and it works great.

P.S. Even with Nexus running on WIndows 2003 enterprize, nexus will still only utilize 4 gigs of ram. The only difference is that Nexus will have more of the 4 gigs to itself and the O.S. can allocate the other memory for itself.

 

[CHM]

Re: Nexus PDF RIP Speed Issues

hi Kristian

The reason why your files are ripping longer than it should is because your sending flattened files trough the Total RIP, and this is normal.
We have don the tests also, when you send a postscript trough the Total RIP it will take up to 10 times longer to calculate.

So if you have allot of flattened files to work with, it will be faster sending it trough the Nexus Postscript RIP than sending them trough the Total RIP.

But now we are having more and more transparencies in files, so the best way to go is to always use the Total RIP. Be sure in that case you never use postscript anymore in your WF and all will be OK.

We have 3 complete Nexus installations here, all running on Xservs, and we are using Total Rip for almost all WF's here.

 

[Kristian]

Re: Nexus PDF RIP Speed Issues

Thanks for the replies everyone.

We have done a few trials over the weekend using one of the files that took a long time to process. A flattened PDF took 14 minutes, but the un-flattened file to 34 minutes! I agree with Joe, what is the point of the PDF RIP if it slows down so much with live transparancies. We were hoping to use the PDF rip for every job but I think we are just going to use it on files that really need the transparencies to be kept live and avoid flattening issues.

Chris, we are not sending postscript files through Total RIP. All our workflows ahve been amended so that they are receiving PDF 1.4, but this RIPs considerably slower than the original PS method.

Kristian

 

[CHM]

Re: Nexus PDF RIP Speed Issues

Kristian, flattend pdf is the same as a postscript, no more transparanties.

What I mean is that if you send flattened info trough Total RIP it will take allot longer to RIP.
In those files you are sending trough your Nexus are there transparencies or not? This has nothing to do with you saving a 1.4 pdf, course if yours design has no transparencies in it, it still is a flattened file and your Total RIP will take longer on it.

 

[Kristian]

Re: Nexus PDF RIP Speed Issues

Ah, I see. However, we have found the opposite in that a flattened PDF processed much quicker which did seem a bit odd.

 

[CHM]

Re: Nexus PDF RIP Speed Issues

yes is a bit odd.

Can you check in your WF what your RIP module is called your using? Is it Assemble Sep..., of Rasterise Sep...?

 

[Kristian]

Re: Nexus PDF RIP Speed Issues

It's rasterise. All our workflows have been changed over to Export PDF and Rasterise rather than PS and Assemble etc.

Are there any settings that can be altered in the export PDF. We have turned off anything to do with Thumbnails and Preview etc. Picture Caching is On and Include Sreenings.

Its strange how everyone seems to have a different opinion on the PDF RIP. ArtProPro thinks its slower for files with transparencies where as you think the opposite. I canonly go by my own experience and say that test file I sent through took 20 minutes longer when the transparencies were left left live in the job.

Kristian

 

[CHM]

Re: Nexus PDF RIP Speed Issues

well you have to consider the whole picture. I mean if your going the old way with flattening it will take allot longer to generate the postscript or flattened pdf.
Here we mostly have complete WF's, we process the file in Nexus and in the same WF we do the ripping. And if we compare those times we see that if you have transparent files it will be quicker in a Total RIP WF.

And I also looked back at your initial post. You where talking about line-work files. SO not allot of images and transparencies i presume. Well in that case the flattened option and the normal RIP will be faster i think.

Edited by: Chris Michiels on Jul 28, 2008 7:22 AM

 

[Kristian]

Re: Nexus PDF RIP Speed Issues

Interesting. Thanks for your help Chris. Will continue using the Total RIP with live transparencies and keep an eye on processing times etc.

Thanks
Kristian

 

[Joe]

Re: Nexus PDF RIP Speed Issues

I don't think it is strictly transparency causing the slow down. I've processed PDF jobs that are 1.3 pdf's with no transparency and it's definitely slower than using the old Nexus RIP. What's really slow is if you want to output a job from the Total RIP to an Appletalk device via Rasterize Composite ===> EPS to PS ===> Appletalk. The Appletalk module is the one with the huge slowdown.