Xmpie output

316 views
Skip to first unread message

Tiff

unread,
Jan 24, 2009, 7:49:04 AM1/24/09
to XMPie Interest Group
Hello
Fairly new XMpie operator and very new to news groups.
I'm producing a job of which nearly all the images are variable. Not
having much experience with PPML which is going to be the faster or
more optimal, producing the job as Pdf or PPML? Or is it just a case
of try it and see? Some jobs work better PPML and some work better PDF
you just don’t know until you try. I out putting to DocuSP on an
Igen3.
Any feedback would be of interest.
Thanks
Tiff

Bill

unread,
Jan 24, 2009, 12:19:00 PM1/24/09
to XMPie Interest Group
Sorry that I cannot answer according to your particular environment...
Please find here-under the durations measured in November 2008 on a
FFPS6 ("DocuSP 6") iGen4 (150,000 recipients, 2 A3 pages duplex per
recipient, background forms covering 100% of sheet size, a hundred
variable graphics, lots of visibility ADORs):
PostScript: 226 A3/minute
PPML: 256 A3/minute
VIPP: 186 A3/minute
Optimized PDF: 153 A3/minute
As you know, this print engine fastest speed is 55 A3/minute.
As you mentioned, this is certainly application specific, and may not
be taken as a universal trend.

couch

unread,
Jan 27, 2009, 1:05:34 AM1/27/09
to XMPie Interest Group
Hi,

In addition to output type, there are many other factors which affect
performance. XMPie has created a new TechNote about peformance issues.
If you contact your XMPie support representative they will send it to
you.

EG one other thing to consider is the image type (are they TIF, PSD,
JPG???). XMPie provides better optimization of EPS and JPG.

Personally, I would recommend VPS or VIPP output formats if supported
by your RIP/Printer. (PPML spec requires encoding of the images which
results in approx 1.5 x the file size to VPS or VIPP - which is partly
why you see VIPP faster than PPML in Bill's results.)

Steve

Dave Cutts

unread,
Jan 27, 2009, 3:25:59 AM1/27/09
to xmpie...@googlegroups.com
Thanks for the info Steve.

Tiff

unread,
Jan 27, 2009, 6:09:30 PM1/27/09
to XMPie Interest Group
Thanks Bill and Steve but,

What about the processing time uProduce takes to produce these files.
I did a job awhile ago and tried both outputs from uProduce. Pdf and
PPML. Yes PPML Ripped faster on Docusp but the processing time and
files size was more. From starting uProduce to final print off of the
printer their was no real difference. Is this something I may be doing
wrong?

Cheers

Tiff

Bill

unread,
Jan 28, 2009, 7:39:37 AM1/28/09
to XMPie Interest Group
Here are the figures (same application, 2xA3 pages per recipient,
150,000 recipients).
Server was dual-core dual-processor 2.7GHz, Non-HyperThreading, only
2GB RAM, which is below XMPie prerequisites.

uProduce Output Average Speed File Size (GB)
License Type (A3 sheets/hour)
MI2 PostScript 6,915 7.85
MI1 VPS 5,591 7.82
MI1 PPML 2.1 5,517 8.80
MI1 VIPP 5,528 7.80
MI1 PDF 2,828 1.12

c0d3gr1

unread,
Feb 2, 2009, 1:57:46 PM2/2/09
to XMPie Interest Group
Hi Tiff,

You'll see a bigger difference in time (just like Bill's numbers) when
the InDesign document has been optimized. As Steve mentioned, if you
use EPS files when using PPML output, the PPML should not only produce
a bit faster, but rip faster too. Of course, this greatly depends on
what you meant by "all the images are variable." Does every record
have its own image, like you'd see when using uImage or do the images
repeat even if they used many times within the document. If the images
are unique for each record, it really won't matter much either way,
PPML or PDF, because in both cases, the images can't be reused and it
will take about the same amount of time as you've already seen.

Also, anoher hint, are the images the optimized for printing, in other
words, you aren't using a 12x18" size image in a 2x3" box? We can
copy fit the image of course, but the image is still the same size and
needs to be RIP'd.

Deb H.

PS EPS files are best for PPML
PSPS for Bill & Steve - most DocuSP (or FFPS) don't have the VIPP
option unless it is purchased, so PPML it is :)
> >  Thanks for the info Steve.- Hide quoted text -
>
> - Show quoted text -

Tiff

unread,
Feb 3, 2009, 4:04:48 PM2/3/09
to XMPie Interest Group
HI Deb

Thanks for that, Yes we have optimized the images to the size needed.
Which helped but we are using uImage. Not just one but 12 uImages in a
booklet.
So as you seem to be saying its just going to be slow. We cannot even
just uImage the area of the image that is changing as the page itself
could be one of 24 differnt images.
Its just a Hell of a job. Thanks everyone. Any one any other helpful
hints all welcome.

Tiff
> > - Show quoted text -- Hide quoted text -

Murray Miskelly

unread,
Feb 4, 2009, 3:44:20 PM2/4/09
to XMPie Interest Group
Tiff,

Just an idea...

I ran a campaign with a single hi-res image with 14 uImage elements
over a large sheet size (560mm x 310mm). There were different
variations for gender, and 14 differing elements for each of these.

The 'cleanest' way to do so and get productivity was to set up the
page with layers for gender (or in your case 24 layers per page) and
on each layer have the static portion of the image as the rearmost
element, and then each of the personalised elements created as
separate uImage pictures cropped as close as possible to give the
smallest file, and then placed as accurately as possible over the
static image.

Use logic to reveal the visibility of the required layer, revealing
the specific uImage elements. (You can also use logic to govern the
creation of the elements so that you are not creating elements that
reside on a hidden layer.

The production time was reduced considerably, as the overhead of
handling multi-layers and visibility was far more efficient then
generating larger uImage content.

I don't know if this equates to what you are trying to achieve, but I
hope that the explanation is clear. Let me know if it sounds
convoluted.

Adam Luther

unread,
Feb 4, 2009, 6:32:29 PM2/4/09
to xmpie...@googlegroups.com
As a variation of what Murray talked about:

You also might want to consider consolodating all of the backgrounds into a single graphic ADOR (placed on the lowest layer). Getting the InDesign document as lean as you can will also help production times, so pulling in the backgrounds from external files can help.

On top of the background layer, create additional layers (as Murray suggested) -- one for each position of the uImage template(s) on the pieces. Cropping down each individual uImage template to its smallest possible size and lining them it up with the remaining static image is crucial.


- Adam

Tiff

unread,
Feb 5, 2009, 7:50:08 AM2/5/09
to XMPie Interest Group
Thanks both Murray and Adam,

I like both ideas. but at the moment I don not do the inDesign part. I
do understand what you are saying but its getting the Design people to
do it. But I do agree I they are both good whys tho get around the
uImage production times.

Thanks

Tiff
> convoluted.- Hide quoted text -
Reply all
Reply to author
Forward
0 new messages