Variable Data file format solutions for EFI Fiery Rip - How to be more efficient?

[Jayhawkmike]

Currently running two Konica Image Press C1100 devices. Our variable (and some of our non variable) projects are getting larger and more sophisticated. We are finding that the variable files generated from our PTI Fusion Pro solution are crashing the EFI Fiery Rip OR ripping so slowly that it renders the device useless until it completes it's task. Sometimes a file will literally POWER DOWN the EFI Rip tower during a RIP. The only think I can compare it to is a 1990's RIP that wouldn't allow you any more tasks until the file was complete. My current prepress workflow feeding my offset work is 10x more sophisticated with multi-threading and the ability to RIP/Trap/Impose/Output multiple projects all at once. Not so with EFI Fiery front end.

I'll pose the question - is this normal? Is it just me? We output PDF files from Fusion pro with 1000-50000 pages (or more). Our work-around usually involves separating the spooled PDF into parts and then going through some type of flattening or rasterizing the file just to get it to process. This usually turns my 10mb PDF file into 16gb or more! This can't be everyone's solution, can it? I'm open to suggestions. I find we don't have many choices with the RIP configured with these printers and no choices at all when it comes to configuring more RAM, HD space or task management. Boxes seem to arrive as-is.

EFI Fiery Rip 5.8
Windows 7 Professional
Total Memory 4 gb (doesn't that seem small?)
865 GB of HD space.

Fusion Pro 9.3.6

 

[Tim-Ellis]

Hello,

What flavour of PDF is your output PDF file?

PDF/X? PDF/VT?

 

[Jayhawkmike]

PDF output from Fusion Pro is PDF 1.5

There is a PDF/VT option from Fusion Pro. I have not tried that yet.

 

[MailGuru]

PDF/VT should help. Try that

 

[Jayhawkmike]

No Title

Thanks for the suggestion - I did some experimenting. I did try one on a 8000 record document writing a PDF/VT. By my stopwatch (wish EFI put a TIME REMAINING on it's interface) it would take a little over 2 hours to RIP. That's a long time. Now the interesting thing is, my document had 8000 pages. The RIP saw it as 4000 pages and gave me a "surface" indication. One side of this project is common with the variable on one side only. My "regular" PDF shows up as 8000 pages. I'll attach screen capture

Maybe this is normal and I should expect no better?

 

[Jayhawkmike]

Well, screen capture was useless so disregard. In the time span it too to write my results here, the RIP slowed down dramatically. I would say this 8000 page document would be in the 5 hour + rip time at this point.

 

[Graeme NZ]

Perhaps try putting all static, non variable elements of the artwork in an InDesign Master page. That way the output PDF only has one instance of the common element which is applied to the 8,000 pages, as opposed to 8,000 instances of each common element.

 

[Tim-Ellis]

Hello again,

Sorry to hear it didn't work. I've no experience with the Konica EFI RIP but for years I have worked with the on-board HP Indigo RIPs and it doesn't sound very different from the problems that plagued us.

If you have 8000 records, what happens if you divide that up into four lots of 2000?

I believe that one HP Smart Stream solution is to divide the output file into manageable chunks and then feed it in one bit at a time. I'm wondering if Fusion Pro can do something similar?

 

[jmarbury]

Have you tried using PPML? Also FusionPro can break up the records into smaller groups automatically as it is composing the file.

 

[Jayhawkmike]

Thanks for the responses. Yes, the "breaking up into multiples" either from Fusion pro or manually out of Acrobat Professional is our current solution/workaround to getting these large files to process. Sounds like I'm doing what everyone else is. About PPML, yes we tried that initially (some years back) but to even less success than outputting a PDF. I want to get with tech support from our Konica vendor and perhaps try the PPML solution again. My goal from the post it to try to reassure myself in that we weren't nuts and submitting these things all wrong. I just can't believe a RIP on a fairly new digital press is that slow. My expectations may be too high.

 

[minder]

I know nothing about digital, mostly Litho. If a file takes to long to RIP or if the PDF has too many components to it (PDF made from Illustrator with layers, masks, patterns), I usually make a Hi-Res Jpeg of the page or file and reintroduce the image into Indesign or other design app and output a new PDF. Speeds up the RIP process time. Hopefully this helps and is part of your problem

 

[MailGuru]

We're using an EFI EX-P (true quad-4 "hyper" rip) front ending our Xerox Versant 2100's. Our merge software is XMPie Server (you are using Fusion Pro).

We started outputting to PPML Extremely large files, slow to moderate RIP speed. We switched to PDF/VT which sped up the ripping process substantially.

It is my understanding that PDF/VT essentially does what Graeme NZ suggested, in that the common art elements are combined and ripped once,
and then the variable images and data are transferred and ripped in to the common elements.

Still, it all has to do with how complicated your variable info is, and, of course, how many different pieces of art are being combined.
With our very complicated mix (over 75,000 different variables and art images) we still would not send a file that is over 2,000 pages.
For instance, a 10,000 page run would be split in to (5) 2,000 page runs. It's just the nature of the beast.

 

[Svang]

Have you try EFI label designer?

 

[LoganBlade]

Try ppml format from Fusion.
That works form mine.

as mentioned above i ussually make it a stack of paper in my printer. 2000 sheets max per file

 

[Print_Curious]

We had similar problems while printing graphic heavy artwork with variable data. Now depending on the extent of graphic content in the variable data it might be possible to send the Master element and variable element separately. Thus the Static part of the job gets processed once followed by the variable.

 

[afilsonCSA]

As others suggested, PPML should help you. BTW, you are not alone in this.

Fusion Pro can output PPML. the EFI Fiery can take the PPML zip file and process it. By doing this your RIP will not have to process the same graphics and backgrounds 30,000 times. It only has to do them once and store them, your variable data will then process very quickly. You will see a noticeable improvement in your RIP times, so much so, that you'll wonder how you ever got along without it

 

[afilsonCSA]

Ohh... one other thing, the EFI Fiery does have the ability to process VDP jobs in their command workstation (you import the PDF background(s) and only send the variable data from Fusion Pro), but it takes some getting used to.

 

[cec-prepress]

I don't have a real solution to offer, but can sympathize. We have Fiery IC-310s (with Hyper RIP) on KM C-1100s and use Fusion Pro as well. We don't do variable jobs with as many records as you mentioned very often (more in the 200 - 5000 range, but 10-20 of those daily). We previously output PDF/VT when we had Creos and they would process really fast and handle transparency well most of the time. With Fiery, we had to switch to regular PDF because the PDF/VT wasn't triggering the Hyper RIP so every page was processing fully instead of static elements only processing once. Multiple people from EFI told us only one variable software outputs a proper PDF/VT format. Odd, since Fiery did see the files as PDF/VT, it just wouldn't process them as expected (or as they did on Creo).
We did try PPML and it worked great speed-wise, but PPML (at least from Fusion Pro in version 9.x) doesn't handle the transparency effects that 95% of our variable jobs involve (they print, but it all gets flattened and rasterized so even text gets very jaggy).
So we're still outputting PDF files from Fusion Pro but there are a couple settings to check in the Fiery Command WorkStation job properties to get the best speed from those. Under the "VDP" tab, check 'Cache PDF and PS objects', and if possible (may not be depending on the job), under 'Define record length', set the 'Pages per record' to the necessary number for the file in question. For example, with a double-sided postcard we set 'Pages per record' to '2'. This basically makes the Fiery treat a regular PDF like a variable file format, but again, may not work with batched/complex variable jobs since each page/sheet may be very different (especially after imposition). We also use the Adobe PDF Print Engine by default, but that may not work for your files.

 

[Digital Press Guy]

"Multiple people from EFI told us only one variable software outputs a proper PDF/VT format. Odd, since Fiery did see the files as PDF/VT, it just wouldn't process them as expected (or as they did on Creo)."

cec-prepress, I'm curious. What VDP software does EFI claim properly outputs PDF/VT?

 

[cec-prepress]

"Multiple people from EFI told us only one variable software outputs a proper PDF/VT format. Odd, since Fiery did see the files as PDF/VT, it just wouldn't process them as expected (or as they did on Creo)."

cec-prepress, I'm curious. What VDP software does EFI claim properly outputs PDF/VT?

I believe it was a solution by GMC. I'm not sure if it would require a certain add-on or how GMC's offering is set up, but when I spoke to a rep from GMC they basically told me the entry price was considerably higher than Fusion Pro. Since Fusion Pro works great for us and the problem only started after switching from Creo to Fiery FEs, I didn't pursue GMC further.