It depends on how they supply the file.

for example:
In some cases no, its just a spoon image with ice cream on it with a drop shadow on the spoon sitting onto of a solid pantone background colour.
Other times its spoon image, then a scoop of ice cream image, then berry images on top of that (all  with drop shadows on the spoon, ice cream scoop and berries)

Would the mask be a defining edge?  or just mask in a few pixels and leave a few on the transparent background in order for Esko to trap with?
Photoshop is not my strong application truth be told.

Hi,

Guess I should have been a bit clearer but my post was getting long

If the image(s) are 4 colours process or at least 3 process colours and are on a process background then there is no need for trapping to occur you are correct.
I think our old prepess operator was more mentioning something like if the image is built out of cyan + black only and is placed on a magenta, yellow background then using our trap ticket these colour traps would not occur?
(at least that is how I took the statement made to Esko)

It was more a images (with a transparent background) placed onto Pantone backgrounds
These never trap without first creating a tight clipping path around the image(s) in Photoshop.

@Tracey:
"Does a "good image" on a spot background trap?
Like you say it may be the way the customer is putting their images in illy."

If the image(s) had a clipping path created in photoshop then it traps just fine.
Unfortunately I do not know what a "good image" is if I am basing that off the Esko supports answer, as I have never had an image trap to a pantone background without having to create a clipping path first in photoshop.

@David:
"Esko should trap a 4 color image to a pms background, it either will spread the pms into the image or it should generate a mask, place the image into the mask and set it to overprint for traps. We used this function quite a bit."

It should but without that clipping path created first it doesn't.  It does not recongnize where the edge of the image/pixels are to where the background is I guess? I really don't know.  At least not from what I have seen over and over.
I have tried every setting I can think of in our trap tickets, and the settings suggested by the Esko support tech
(suggested to the old prepress operator who opened the ticket 2 years+ ago)
It just ignores the trap that should occur.
If I try to trap the image to the background in Illustrator using the Esko Deskpack plugin trap objects tool it comes up with the following: ' no common edge could be found for trapping'

I would be creating a .pdf prior to import into AE

@Digicorn:
Creating a clipping path around the image (without including the drop shadows) & filling this path with white that is 4-6pixels contraction.
Then going into illustrator, placing this contracted white KO behind the original image and setting the original image to darken or multiply
works sometimes for creating my own trap and it keeps the drop shadows the artist used in their original layered photoshop image.

Needless to say its time consuming due to still having to create the clipping path in the first place to create the KO for each image. : (

I suppose I will have to open another ticket and see if they will assist.
I find Esko support... not that helpful and are VERY quick to close a case regardless if the suggestion they gave works or not for the issue(s) stated.
** Ticket Opened, they are looking into it.  If they find a solution then I will be sure to post it as a reply to my long winded post

Odd title but I wasn't sure what to call it.

Since starting at my new workplace and using Esko Automation Engine 14.1 (currently installed) I noticed that clients would supply us .ai files with images (on transparent backgrounds) linked in [.tiff, .psd, .jpg(ugh)] the issue I have is when I run these files through our trap ticket  it always omits trapping the images to the background.

It gets worse when the .psd files have drop shadow layers in them.
Usually I end up just setting a clipping path around the image (and not the drop shadow) then going into the file, duplicating the image, and relinking the top most image to my clipping path applied image. (basically sandwiching the images ontop of one another, with he original image and its drop shadow in tact) 

Is this method risky?  totally crazy?  ... seems to work and beats  sandwiching 3+ images to get one that will trap in esko: just the shadow.psd / middle image with clipping path applied.psd / top most image with clipping path applied.psd ))

One particular graphics house does not use clipping paths (well I'm sure they do when creating this knockout) and instead creates a white ko behind the image that is contracted about 4pixels, then sets their main images to darken, thus creating a trap.. tho one thats more difficult to edit if the need arises]
I have used this method as well but finding the right pixel contraction to use on the images so you do not get too much or too little trap is tough as it tends to vary on the overall images size.
4 pixels on a tiny image 1x1 inch is too much but seems ok on an image thats 3x3 inch

I ran through some requested help cases which the old prepress operator had submitted to Esko support.
In one he mentioned that the images in his files were not trapping to the process background / pantone background in his files.

The help desk had assisted him and then closed his case.  Unfortunately they do not leave good notes on what the resolution of the case was.
I can tell by what is in the notes that they had told him:

Esko Support:
"The transparent bkgd does not provide any pixels to extend in order to create the trap.
The only way I could get it to Trap was to increase the Trap amount for the images and the trap direction for the spot to go into the image.
It is a file issue, if there is not data (transparent pixels around the image) then there is nothing to spread into the spot color. It would be better to actually have a tight clipping mask around it."

Which lead me to always having to create a tight clipping mask around the images in the files supplied to us (by almost every customer, and we have many)
Normally, not a huge issue but when certain customers supply 10 to 30 files with 2 to 4 different images in each it can take hours and hours of extra time spent creating a close clipping mask (1200%to 1600% zoom level) around the art for Esko to then realize there is a path/edge and trap the file/images properly.
Without this path Esko will not trap the image(s) to the background.

I have tried setting the ticket to how the support suggested and it does not work. 
I have set the trap to 1pt just to see and it fails to trap.

So is there any way to get images to trap to process or pantone backgrounds without having to spend extra time creating clipping paths in photoshop?

I have suggested to the artists (and it is within our spec sheet) that this step needs to be done on their end. (haha)  quick selection tool and/or lasso tool...beyond sloppy (or just not done at all as it takes too much time...."go figure"
Of course, when we try to charge them for this extra time it's an issue
(one which we end up on the losing side of)

If i send the files back nothing would ever get done file wise as it occurs with 90% of our customers.

Sorry turned into a bit of a rant there at the end : )

Thanks,
C2V

So I ended up getting this to go through from save out to layout to tiffs.

Process was (in case anyone is curious):

Source Art is a Separated DCS file (.EPS) with accompanying separation files (.C, .M, .Y, .K)

Rip (all at once) separated files (.C .M  .Y .K) through Esko using "Copy Dot" ticket.
( which creates a pdf wrapper pdf file, basically combines each separate file into a single pdf

*my mistake originally was just ripping the .EPS through Esko, it would create a pdf that looks the same in viewer as the pdf created using the individual files above but somewhere near the end steps Pandora just would not work with it

Indesign:
Place the newly created pdf into Indesign.
Place company dieline, marks & slug on top most layer.
Save Out As: Adobe PDF Presets / Company Hi Res PDF export setting.
Rip this pdf through Esko using the  "Normal Workflow_No Trap" ticket
Views alright in Viewer but the more you zoom in the better it starts to look.

Pandora:
Place sheet size / press size & .cf2
Drag the normalized .pdf into Pandora  (making sure Pandora was set to "Use Vector Dieline from Artwork" in preferences)
Place all needed press marks ect.
Save Out to .jdf
Rip .jdf through Esko using "Imposition Output from JDF" ticket 
(creates a imposition .pdf & rips to TIFFs & prints a lo res layout proof)

* This is where usually the art would unsnap from the .cf2 and just kinda be placed wherever on the imposition.
i thought it had something to do with the settings in the ticket...I am still unsure as to why this time it stayed in place.
Perhaps the Snap to Vector Dieline option in Pandora?? *

Creation of TIFFs for review prior to release to trendsetter for plating (these TIFFs looked OK)

-C2V

Much appreciated

Hi,

Guess I needed to state that from the start, sorry about that.

Esko Suite 14 (I believe there is 16 available now but we haven't upgraded yet)

CAD is using:
Artios CAD

Macs are using:
Automation Engine, Pilot, Shuttle (which we do not use at all), Cape (tho I do not use it )  and Deskpack Advanced 16.0 plugins for Illustrator. (& the license manager for it all) Were also running a trail version of Studio (basically to create 3d pdf mockups.. a waste perhaps)
& a trial version of Plato on our old PC (which neither my coworker or I like, even after the 3 day training provided)

Hi,

When i take a look at the insides of the Wrapper ticket the "Export to PDF" module shows 'composite' under output type so It looks the the wrapper ticket combines them.
I wouldn't think Pandora could handle anything else, it throws up the red X's over any little thing.

That is indeed what it looks like. Which is great.

The Pandora layout is a stepped .cf2 file (in this case 2up with a head turn)  which we import (cf2 is created by our CAD dept)

See and they were promoting Plato like it was WAY better than Pandora (or Kodak in general) and that it will solve all our issues.
Were on a 3 month trial of Plato and got training for 3 days.
It causes more issues than solves (basically everything has to remain perfect and exactly as is from the start (cf2 direction, art placed into that dieline, and other things) otherwise we find were just back tracking because Plato will not work as fluently as suggested.
(at least Pandora is simple and when it works user interface friendly) I find most Esko products (again I'm new to them) are....overly complicated. They have an option for every single little thing and then 3 other ways to modify it.. its overwhelming.  (training may take some of that overwhelming away but we do not have the time to send me to training -- so the online help and online manuals are my go-to if needed)

The trainer mentioned theres a new product coming out soonish (I forget the name) which is pretty much Plato 2.0 and has way more features and Plato would be less supported.
My co worker and I just thought, then why are we learning this application if its going to be obsolete in a year... or can't do what we need but the next big release would have features we were asking about...
anyhow....

The AE ticket takes the stepped layout and converts it into a pdf
in-between the start and the end of that process it allows us to stop and map colours, omit colours & change screens
I am sure theres even more it could do, but the Esko people and the old prepress guy (who doesn't work here) set it all up at the time.
We already step it X up in Pandora during the import phase. (import .cf2, then import art (.pdf) )then save out as .JDF.
(( why we need to export as JDF then create a PDF is beyond me. Why not just omit the JDF to PDF part and go right to PDF?even if AE needs to rip it after ?  ...perhaps its not possible?, I do not know enough about Esko and what the ticket they setup does...
i know ignorance is not an excuse but.. lack of knowledge...truth) : )

I appreciate the chat and assistance nevertheless.

C2V

Hi,

Thank You for the reply.

The DCS file(s) are multiple part.
They came as a set with:

"filename".EPS
"filename".C
"filename".M
"filename".Y
"filename".K

The only reason we  are using Indesign is to get our Dieline, Marks & Job info on top of the file prior to output.
One single file with all the Prepress required info in it.
I totally get just importing the .pdf created by Esko and adding in another file or doing the marks in Pandora, but " that is not how we do it here"  *rolls eyes*  ( I do not setup the layouts, just the art )
I can suggest this again (as I have had to use a separate file containing the Dieline/Marks/Job info in the past / at my last workplace)

Good thought.
I just took a  look at the wrapper ticket and there is a definite angle in the inks tab where it looks like you can change the ruling and angle. (they are set to our default angles which we use here)
The dpi I believe I can get by opening one of the "filename".C  in text .....  yep:  2438.000000 x 2438.000000 DPI
Our rip screens at: 2438 so shouldn't be an issue there.

Nope, nothings changed. It's still a very simple but fickle program that really isn't supported much
(even if you call the help is ...subpar in my experience, and expensive if your not on a contract. *which we are not*)

Nope. I wouldn't have though that would work, but I guess it should.
Theres a real strict set of steps I  am supposed to follow and trapping prior to input into Pandora is on that list.
but that is something I will suggest our layout person try.  ty.

Our plants seem to have it and still use it (we switched to Esko and slowly the rest 'should' be in the future
We were the guinea pigs.

We've looked into Plato for our layout program but find its too picky.
too much to go into with that statement but we found it takes longer and crashes far too much for us to use.
(also we would need a PC or emulation via Parallels to run Plato)

----------

What I ended up doing is instead of wrapping the .EPS file using the Esko ticket I wrapped the .C / .M / .Y /.K files into a Normalized .PDF
Placed this .PDF into Indesign and added in our Dyeline, Marks & Job information.
Saved out as a Hi Res PDF
Ripped that Hi Res Pdf through Esko (using no trap ticket setting)
This PDF does work with Pandora!  (yay)
Snap the Art to the CF2 and add in any additional press markings in Pandora.
Save out as a .JDF
Send the .JDF through Esko to create a final layout .PDF
(during this step we map colours and set screen angles if needed)
Then send the .cip info to our press.
We then send it to our tiff catcher which creates final tiffs for our trendsetter. 

But

When we save our layout as a .JDF then rip it through Esko so it becomes a final layout .PDF

When this .PDF is generated the art is shifted off the CF2 file.  (either Pandora or the Esko workflow is causing this)
which leaves our final layout .PDF unusable.
There are settings in Pandora for it to use the Dieline or Trimbox settings but neither seem to matter which makes me believe its a Esko setting somewhere when were taking the .JDF and creating a .PDF.

I feel I'm close with this file but not quite there yet.

Thank You for the reply and suggestions on what to try!

-C2V

Hi,

Frequent browser but never joined or posted.
The community seems very helpful so I figured I would give it a shot and see if I can get any assistance.

Currently working with Esko and we have a few customers who have never updated their art and we need to get them through to plating.

A previous employee here had contacted Esko support regarding DCS and Copydot files and working with them using Esko workflow.

While I was not around for the conversation (as I was not working here at the time) they did end up setting up a wrapper file ticket for us to use.
(basically takes the .EPS and wraps it a .pdf)

I can get this file through Esko by:

placing this generated .pdf (from the Wrapper ticket) into Indesign.
Dropping in our company marks and colour dots and job # information.
Saving as a Hi Res PDF out of Indesign.
Ripping that high res pdf through Esko using our regular rip/trap ticket created (it was here when I started and seems to work for everything but these files) (we also have a ticket that is an exact duplicate except it does not trap a file)
Automation Engine viewer can see this final .pdf but everything looks ... moire patterned ( in Prinergy this was common and the files ended up plating OK despite the virtual proofers viewing of them)
but
When this pdf is placed into Pandora (as it is the layout program we are using) it just errors and we get a grey box with a red X in it.

When we go to Esko for assistance, they mention Pandora is the culprit and Kodak mentions Esko is the culprit (perhaps bit of both..)

Any idea on how we would use DCS/Copy Dot files with Esko?

I asked my co-worker and they used Rampage prior to Esko (Rampage is....odd and there seems to be no info or available training on it anymore, and they wouldn't train me on it anyhow.. I never received training on Esko either. (theres no time, i am the only operator who works with files) (been running blind for the last year, but so far so good)
We currently can't use Rampage as were having issues with the server its hosted on (permission issues) and our tech whom we hire in on as need basis insists that its not a server or permissions issues with Rampage but because we upgraded the OSX and CC suite.. (he's incorrect but won't budge on the issue so far)

Our short term work around is to send the files to our sister plant and they create the tiffs needed but its not a viable long term solution for us.
I have suggested these customers get a refresh on their art since we cannot work with it in our currently supported workflow and the sales are hesitant to ask them to do so. (why stir the pot apparently)

Thoughts?

Thanks,
C2V