Trap generation taking too long, what can I do?

Is there anything I can do to help this file process faster for the platemaker?
The software is Platestream (I think) and as it brings jobs in for burning to plates it does this “trap generation” usually this goes so fast and the job is in the queue in under a minute. This particular file is taking over 1.5 hours for one plate.
Any ideas on what I can do to the file to make it process faster?
The original job was sent from indesign with linked .ai objects, and then later as linked pdf objects, and then finally as embedded pdf objects.
All tries resulted in the same slow trap generation.

I’m not familiar with your software here, so I can’t give you any specific troubleshooting tips for that, but I can give you some general ones based on the file you described.

Are the linked .ai or .pdf files large in size, or complicated in their image contents? I’ve had issues preflighting files for other output and sometimes complicated vector objects or large linked files slowed it down significantly. In those cases, I found rasterizing the large and complicated files at my print resolution helped a ton - the processing program/s stopped trying to read the complicated formulas and read the pixels much faster. You just have to make sure you’ve got your quality settings where you want them, and that the file doesn’t get -bigger- on rasterization - which is usually only a thing that happens when you’re exporting at a very large size and/or very large resolution.

Hope that helps, and good luck!

This absolutely worked. I exported the pdfs as jpgs (300dpi etc) and then relinked to the raster files. The file was processed by the platemaker in seconds. The file is pretty pretty text heavy and all of the text had been converted into compound paths so your explanation makes sense.
It’s always such a simple solution, isn’t it?
Thank you!

This might have been the real cause … not sure why you would want to do that.

100% was - type would have been Rastered on output to 2400ppi.

Now it’s only 300ppi.

ugh, 300ppi jpgs???
No.
jpg is a lossy compression format.
But whatEVer…

I remember when I first started out we had a job going on press and it wouldn’t go through the image processor (to make film).

So - the gimp of a boss decided to rasterise the beautiful vector and did the exact same thing - made it 300ppi jpeg.

I was shocked!

He output the film and it was rough - really rough - and he said to go with it and went to a meeting.

I didn’t want to go ahead with it - so I tinkered with settings and output some film on the imagesetter - it looked x1000 sharper.

I went with that.

I never told him.

That’s called enabling, LOL. You made him look good.

Well I was down that road with him before.
And he changed something else that he wasn’t supposed to - on me - the junior (25 years ago).

I objected, he said I didn’t know what I was talking about (probably true). So I went with his. It went tits up. He blamed me. I said, I’m the junior, I asked him on Tuesday 11th February and he said do this.

God bless my written books of changes… anyone still do that ?

I have saved emails back to 2014 for that kind of thing, LOL

Ha true - probably why I transcribe phone conversations to email for approval.
And if someone asks for something in passing I definitely reply with ‘send me an email or it won’t get done’.

Ah digital!

1 Like

Oh, yeah, the old, “but I told you over the phone” thing. Like you say, those get sent back for a reply in email. Text is another big hairball too. They don’t get saved to the company records. So a lot of times, if critical, I’ll send an email for those too.

1 Like

Yes, if the type was a solid black to begin with rather than being composed of screen tints. For small, black text, rasterizing it would certainly be a quality killer, bring the text resolution down to half that of an inexpensive laser printer.

Yup, nothing like compounding the problem with JPEG artifacts.

That’s true. If trap and spread generation bogs down due to overly complex vector data, rasterizing the data will eliminate the problem. But wouldn’t converting everything to a flat bitmap also eliminate the traps and spreads? Wouldn’t it have just been better to turn off the trapping (if possible) and simply output the file at the platemaker RIP resolution of ≈2400 dpi rather than converting to a much lower 300 ppi bitmap, then compounding the image degradation with lossy compression?

I’m not saying that this technique couldn’t be a good workaround in just the right situation where a low 300 ppi was appropriate and little to no trapping was needed. At the newspaper where I used to work, when similar kinds of problems presented themselves on the old imagesetter RIPs used at the time, I’d sometimes rasterized vector data to 600 ppi to keep the edges relatively clean — at least for newsprint.

Yeah, we never take instructions over the phone. Anything not in writing will be ignored and we tell all our clients that.