Xmpie / docusp issues

[p775]

Hi Everyone,
I joined this forum looking for some insight into some issues we've been having at the printing company where I work as a graphic designer/IT manager.

We have a client who prints roughly 50-60k VDP postcards each week. The workflow is as follows: laid out in indesign using xmpie udirect standard 4.6 > linked to csv file > a "data"(variable data fields only) and "master"(backgrounds only) file are then created > master is sent to the docu sp software on the front end of an igen 3 >data file processed in chunks of ~3k records 9 up > data files sent in pdf format to docu sp > master and data merged on docu sp> print

We now have a problem. Instead of printing straight text, the client is now using a design that has heavy effects applied to the variable text fields. When the pdfs are merging in the docu sp software, we are getting the huge white knockout boxes overtop of the background image.

I'm very familiar with the knockout/transparency issue and have resolved it in the past by changing the version of acrobat compatibility level, or by removing spot colors. There are no spot colors in this job, and switching to acrobat 6 compatibility from 5 did not help.

Xmpie support tells me that it's the docu sp that isn't merging the data correctly. They recommended several workarounds that will just not work: a.) creating postscript files - files too large b.)merging data and master from xmpie - files too large, processing on xmpie and docu sp too long c.)ppml - again, files too large. When I say "too large", I'm talking about 20 records resulting in a 182MB file. Again, we're used to doing 3k records at once.

I understand that the effects are the bottleneck on the processing machine, but the docu sp is not combining the files properly either.

I manage the entire frontend with indesign and xmpie, but a press operator manages the docu sp system of which I have no experience or knowledge (other than him telling us to "flatten" files or to re-send them because they are not processing). The processing machine is a mac dual core dual processor 2.6 xeon intel system. By ways of comparison, our regular text only records process at roughly 5 per second. These new files (processing only the data templates) take roughly 2 seconds per record. We know that a hardware upgrade on the front end may be inevitable, but I figured I'd ask here to get some ideas from other people who may have experience with xmpie or other alternative plugins that may work quicker, or produce files that are more manageable by the docu sp software. Any help or advice is welcome! Thanks!

 

[pcmodem]

The first thing I would do is make sure your DocuSP is on the very newest version. The newer versions work better and can deal with transparency native...from what I have been told.

 

[p775]

The first thing I would do is make sure your DocuSP is on the very newest version. The newer versions work better and can deal with transparency native...from what I have been told.

Thanks for the reply! This is something we will be checking into on Monday.

 

[JasonFF]

I wouldn't count on switching VDP programs to lessen your processing time either on the computer or at the RIP. Some other programs, from what I've read, are slightly faster than XMPie output and some are slightly slower, but none, especially if there are heavy effects are going to be significantly quicker.

If I have a VDP project with heavy InDesign text effects that cannot be removed or made part of a static background, then the best method I have found is to process records of 500 at a time and turn on XDOT, and output as PPML. Using XDOT will rasterize the variable output that contains the text effects, which makes it significantly faster when RIPping. Using PPML over PDF also helps with RIP time. By setting the records you process at a time to 500 or 1000, you lower your waiting time when ripping. If a 3000 record file would take 2 hours to rip, the 500 record file should take less than 30 minutes to RIP and begin printing. While that is printing, your subsequent records 501-1000, 1001-1500, ETC can be processing. This keeps press time optimized, and using this method is what allows us to maintain a smooth workflow even with ridiculous VDP projects.

You do end up with multiple output files that most likely need to be renamed and set up in the RIP, but we do this even for runs of 100000. The RIP time we save is always worth it. As someone else mentioned in another thread I recently read, you could also use the uImage XMPie plug in for Photoshop, which can be used to add any number of text effects while reducing the chance of a knockout / transparency issue ever occuring. Text effects in InDesign are definately the bain of many a VDPer.

 

[p775]

I wouldn't count on switching VDP programs to lessen your processing time either on the computer or at the RIP. Some other programs, from what I've read, are slightly faster than XMPie output and some are slightly slower, but none, especially if there are heavy effects are going to be significantly quicker.

If I have a VDP project with heavy InDesign text effects that cannot be removed or made part of a static background, then the best method I have found is to process records of 500 at a time and turn on XDOT, and output as PPML. Using XDOT will rasterize the variable output that contains the text effects, which makes it significantly faster when RIPping. Using PPML over PDF also helps with RIP time. By setting the records you process at a time to 500 or 1000, you lower your waiting time when ripping. If a 3000 record file would take 2 hours to rip, the 500 record file should take less than 30 minutes to RIP and begin printing. While that is printing, your subsequent records 501-1000, 1001-1500, ETC can be processing. This keeps press time optimized, and using this method is what allows us to maintain a smooth workflow even with ridiculous VDP projects.

You do end up with multiple output files that most likely need to be renamed and set up in the RIP, but we do this even for runs of 100000. The RIP time we save is always worth it. As someone else mentioned in another thread I recently read, you could also use the uImage XMPie plug in for Photoshop, which can be used to add any number of text effects while reducing the chance of a knockout / transparency issue ever occuring. Text effects in InDesign are definately the bain of many a VDPer.

Thanks for the post. Basically we have found that the only way to proceed with the heavy effects oriented project is to move to uimage or a uimage server. There is simply no way to process at a speed that is acceptable with the equipment and software that we have considering the turnaround time needed due to customer DEMAND and postal mailing deadlines.

 

[Gbane]

DesignMerge

DesignMerge

Greetings,

DesignMerge Pro is the answer you are looking for. We will assist you every step of the way to ensure your success in producing your VDP jobs. Call us and we will show you how.

Regards,
Greg Bane
DesignMerge Channel Manager
888-983-6746
Meadows Publishing Solutions

 

[Bo3b]

XMPie is a bit silly with the way it handles transparency in the static elements. I've found that if you have any transparency effect on static elements AND transparency effect on variable elements then you will get a large graphic element created that will incorporate all elements with transparency (draw a big box that includes every transparency effect on the page to get the idea of how big this element will be - in some cases it becomes the whole page. XMPie will also include elements on layers that are set to invisible/no-printing if they also have transparency effect applied.
If the static elements can be exported and re-placed as an image this will help. You can also try using different techniques for getting similar looking results ie for a drop shadow you could try duplicating the text line, changing colour, offsetting it a bit and sending it behind - doesn't look quite the same but would be similar and would process MUCH faster.
Although XMPie can handle transparency it is still best to avoid using these effects if you also want fast processing and or small files.
That said, xmpie is constantly getting better with each new release

 

[Deefecto]

Just came across this after having similar issues, drove me bananas as i couldn't figure out what the heck was going on. I was woking on a double sided pass card of sorts that had drop shadow effects on the variable text on the front, whilst on the back of the card, variable text with no effects. On output, I had some of the plain text on the back vanish. I then pretty much stripped all elements bar the text and still had it happening. I guess it had something to do with not liking the effects on the front side of the card maybe??

Overall is it better to make up the graphic elements/variable text with effects in Photoshop or InDesign or is it just better to try and avoid transparencies altogether when designing artwork with variable data?

 

[Bo3b]

For best performance I'd avoid transparency effects, especially on variable elements.
You could use Transparency on static elements but for best performance I would pre-flatten these - i.e. create all your static elements in Indesign(or whatever) then export the entire static elements on the page as an eps or tif - this will flatten the file - xmpie will no longer 'see' these elements as having transparency applied.
The latest version of xmpie can now export a pdf as PDF/VT - this does a much better job of handling the transparency elements, no longer creating huge graphic elements to encompass all the transparent objects, now all the objects are exported separately. For best performance/compatibility you would then want to send the pdf/vt files to an APPE rip as printing a pdf or sending a pdf to a CPSI rip will have to convert the pdf to postscript and in that process will flatten the file. APPE should handle the transparency natively.