Forum > Esko

Esko & DCS / Copy dot files

(1/3) > >>

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

EmptyWords:
Ok, so let me take a stab at this, even though we are still stuck on the old Artworks/Esko workflows and have not moved to Automation Engine (at least yet), we did a while back have to work w/ CopyDot files, like you are currently dealing with.

The DCS files in question, are they a single pre-screened DCS file or are they a multi-part DCS file you are submitting to the Esko AE workflow?

Since you are using Pandora, I am not sure why you are using InDesign, we would just import the pdf that AE generated from the DCS file into our layout software (we use PowerLayout/PowerStepper, not Pandora), do the marks, color bars/dots and job information, then submit that to the workflow.

On the moire issue, sounds like AE maybe re-screening your files. I don’t know if AE has an option to not screen and skip a pre-screened file, but that might help if it does have this option available to you. You also have to take into account what dpi the CopyDot files are 2400/2540 etc and if your rip is re-ripping/screening to a different dpi. 

I have not touched Pandora in at least 12 or 13 years, we tested that out along side of Esko’s PowerLayout and opted for the latter, but I remember that Pandora had issues with some pdf files we tried to import, that was sometime ago and things may have changed. 

Have you tried to import the pdf file that AE made from the DCS file directly into Pandora, bypassing the InDesign import/export high rez pdf/AE rip&trap steps and do your marks, colorbars and info directly in Pandora, then submit to AE to rip/trap? That may fix the issue w/ Pandora generating the error.

As far as Rampage, FujiFilm acquired the company and Rampage is no longer in business or supported to my knowledge, Fuji did for sometime support Rampage but everyone I know who used Rampage have now switched to Fuji’s XMF workflow or other system.

EW

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





EmptyWords:
No problem, glad to try and help even though we don’t currently use Esko Automation Engine yet.

The reason I asked about single vs multiple DCS files is I am wondering if the convert to pdf in AE combined the DCS sep files into one or kept them separated but just w/ a pdf wrapper, I know we had issues when we were testing out Pandora and trying out various types of files, that might have cause the issue of the error in Pandora.

Looks like the Normalized pdf might combine the seps into one to play nice with Pandora?? Don’t know but glad you at least are able to place into Pandora without the error.

Is the Pandora layout a 1-up or a stepped up file that you export to the pdf file?

Plato is pretty much a dead program too, we looked at getting it a few years back when we got frustrated with Kodak and though of moving away from preps, but our sales rep and the software engineer we met with pretty much said find something else, it’s too fickle and will never move forward from where it’s currently at.

Does the AE ticket to make the final pdf layout do the stepping of a 1-up from Pandora?? Might be something going wrong w/ the stepper in the AE ticket, if so, have you tried to step the file in Pandora and submit that to the rip/trap ticket. I am not really familiar with AE yet, so am taking my experience w/ Nexus/Odystar, which AE is based off of, so I might be missing the mark, since they are generally the same but different workflows none the less.

Maybe someone else here might chime in with other ideas to help.

EW

C2V:
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

Navigation

[0] Message Index

[#] Next page

Go to full version