Pre-Seperations file with collections for output preflighting

[russpears]

I was told to send a seperations PDF file to the printer through a prepress video tutorial (InDesign CS3 Prepress Essentials with: Taz Tally).

When most printers will only be using the original file or Printer file to send to their own RIP, I do nto know why the printer will find a pre-seperated file benificial. What is the purpose of the designer sending separations PDF file? I read that I is good practice to review a seps file to locate drop out images, spot colors, trapping and other issues and I was told that the printers just use this as an assurance against any issues they may encounter with creating the printing plates? Is there more to this?

 

[Tech]

Re: Pre-Seperations file with collections for output preflighting

Taz appears very knowledgeable, but I get the vibe that he is more of an armchair prepress consultant/writer/trainer. I have not yet encounter a printer requesting pre-separated PDF files.

 

[mattbeals]

Re: Pre-Seperations file with collections for output preflighting

Pre-separated PDF????

Run.... fast.... very fast....

So if you provide a pre-separated PDF I assume that you'll handle all the proofing, trapping, imposition and screening too. In which case you might as well buy your own press too so that you can take into account the dot gain and other mechanical factors.

Pre-separated *anything* is something I haven't seen in at least 10 years. There are certain times where I can see wanting to control the separation of images but I would never send a pre-separated job to a printer.

Run... fast... very fast....

 

[John W]

Re: Pre-Seperations file with collections for output preflighting

Please allow that some printers especially specialty printers such as folding carton printers have significant parameter requirements that include many things that the originator or facilitator of a pdf never heard of nor wants to understand. This is my argument for native file workflow. It proves itself to me day after day. I do not want to get into details now but if you disagree with me, then I will explain the details at another posting.
We still use a separated workflow because we trap by hand that is to say at application level. All the auto trappers I have tried and continue to try from time to time, fail to trap correctly when files include rich blacks mingled with spot color line drawings, metallic ink, foil and emboss, braille spot color issues, use of opaque white, nested flaps with dead cut dies and the list goes on and on. The only trap systems that can cut it are after rip raster trappers and old fashion LW/CT systems, IMHO.
So if our client wants to provide pdf, it has to be separated pdf and as you say, in a finished print ready state one up. But of course we prefer native files because of the numerous edits we must do everytime. We will accept a pre-separated trapped screened and angled stitched back together DCS2 file for those who need a so-called locked format. But both these methods require considerable pre-production discussion to allow a smooth flow.
So please do not run away too fast until you speak to the printer. Prove me wrong; no one has been able to yet and stay as efficient and on budget! Of course our method requires application skill, no question about that.
John W

 

[mattbeals]

Re: Pre-Seperations file with collections for output preflighting

Well since you are in packaging the idea of providing a separated PDF in general is a scary thought. It can be done well by people with knowledge and experience. But on average it's a horribly bad idea because most people don't have the knowledge or experience. In packaging a native file workflow still works very well. In my experience it is still the most efficient way to work rather than a PDF based workflow. But even then, it's still a composite workflow.

If you're having a problem with trapping software and rich blacks, amongst other things, then that proves even more so my point of it being a bad idea. I doubt I could provide a separated PDF in a print ready state suitable for packaging printing. Sure I could follow a spec sheet but that's only part of the procedures.

There's only so much a content creator can practically do for the printer. There are lots of things that they "can do". But just because you can doesn't mean you should. If the content creator is willing to put in the work then go for it. I did the same thing with PDF/X-1a and my own contract proofs. But I spent a lot of time gathering the knowledge, the experience and communicating with people. It is the most cost effective way of doing things that I have found. But that doesn't mean every can do it. Some don't have the skill or knowledge. And some don't want to have the skill or knowledge. More often than not though they do not want the responsibility.

Well crafted files by a person with the knowledge and experience will always be smoother to produce. But to say to people in a training video to provide separated PDF's for their work in general is a *very* bad idea.

None of what Taz may have said or you and I have said will ever negate the need to communicate with the printer. It's amazing how much "communications" we generate but how little communication there generally is between the people designing the art and the people printing it. Even though we're all in one form or another of "communications".

 

[russpears]

Re: Pre-Seperations file with collections for output preflighting

I really think this makes a good argument here, How can the designer know a printers press condition at preflight time and how they want to position the art for the plate. But I will look into it more because I think it will be great to send files ready4Press-if even possiable.

Now do you think the seps file can be usefull as a content and setup proofing tool?

 

[John W]

Re: Pre-Seperations file with collections for output preflighting

I agree. I only want native files. We have one large client that insists on a locked format so we as printers cannot goof it up (in their mind). So they have a high faluten prepress house provide us with separated pdf because we do not use a composite workflow. I do not want to have two workflows to handle the 30,000 legacy files I use one way and a composite run the other. So the separated pdf was the compromise.
You are correct, it is scary since even a separated pdf (basically should be a B&W) can and does house transparency which will cause the application of choice and the rip to create different results; seen it, done it, and fixed it.
However, in general, the fewer the variables, the safer we are. Pdf was supposed to reduce the variables but what it has actually done is create new variables hence the need for PitStop, Neo, File Juicer etc.
So in order my choices are 1. Native, 2. DCS2 (pre-separated), 3. separated pdf.
I will hold to this as long as it is the most efficient, cost effective and accurate method for this type of work.
John

 

[call_me_ted]

Re: Pre-Seperations file with collections for output preflighting

Half the files I get will not separate as the designer intended (rgb images, cmyk used in a spot job, etc.).
I'd love for my clients to produce colors seps so they themselves can see if their job will work.

 

[Verve]

Re: Pre-Seperations file with collections for output preflighting

if i may..
within the print industry, the exchange of digital data has been a major concern eversince the introduction of the computer as atool in the preparatory process. although the exchange of the data in the varioius proprietary format associated with application programms has been common, the ability to use standard format to exchange data is the goal of the industry. proven that PDF has been selected as the exchange format to eliminate the possibility of conversion errors(or to make them unlikely as possible) this data format to be least sensitive to conversion error CGATS.12/1 Part 1Complete Exchange (PDF/X1a). Now... from my experience, the biggest problem with data exchange is errors in the file which make further processing impossible... main issues here is the file generated by these so called originator (designer) did not compatible to our front end workflow.....Well, in specialty printing( Packaging ...etc..)i would go for native files...but in print publication i.e magazine which demand a very tight deadline for sure will go for PDF/X1a...

 

[russpears]

Re: Pre-Seperations file with collections for output preflighting

As a Best Practice what files should I include with every design project? Now I’m thinking from the designer’s perspective only and from a concern for legacy problems:

PrintReady .ind (For printer who want to work with native files)
PrintReady .pdf (PDF/X-3 or higher for transparency support.)
LowResComp pdf (To ensure placement issues and Copy flow)
Seperations .pdf (As a second level of important quality checks only)
Images Folder (uncompressed CMYK .tif and .psd files)
Fonts Folder (I will be using only Opentype fonts from pro sets)
Native Files Folder (holding all source files worked from)
ReadMe.txt (For any designer notes for printer)

All of this placed into an uncompressed zipped file along with copies of the two print ready files -This is to insure no future support for the zip file.

Now this seems like a lot but I guess memory will not be an issue for a freelance graphic designer.

Any other recommendations

 

[John W]

Re: Pre-Seperations file with collections for output preflighting

No, not Indesign and not Quark for folding carton and other 1 up packaging design. Only Illustrator, period if using a native file system! If a pdf or quasi pdf workflow is used, then Indy or Qxd can work as well as Illustrator. Therefore illy works for all systems as a print ready starting file hence my comment.

Use Indesign or Quark for page layouts such as pub work, textbooks, manuals, calendars etc. But use Illustrator (or equivalent vector programs) for files to be made into three dimensional pieces once completed. From Illustrator the printer can go forward in nearly any direction with little or no hassles.

John W

 

[russpears]

Re: Pre-Seperations file with collections for output preflighting

Yea, illustrator is better for single page design. I just used ID as an example. But thanks for the stipulation.

 

[rich apollo]

Re: Pre-Seperations file with collections for output preflighting

John's situation is specific. His need for Illustrator files has to do with the demands of his output processes. If you're not doing things that require intricate die cutting then I'd say do NOT use Illustrator for page layout. There are scads of reasons not to do it starting with unwanted color changes and ending with the fact that Illustrator won't collect (or gather or assemble) your fonts and images for you.

I'd say don't send pre-separated files either. Pre-separated files are almost unusable, and you can check all your overprints without going to this step, now. Since you can utilize separation previews, pre-separated files have no value.

rich

 

[russpears]

Re: Pre-Seperations file with collections for output preflighting

Good reply Rich, and so it looks like the native file can vary but you both think the seps file is a bad idea. Yea I can soft proof in Adobe, but collecting for output is easyer in ID. However a good designer should only use a few fonts in single page layouts. However, what about the color changes you mentioned? What can happen between Ill CS3 and ID CS3?

 

[rich apollo]

Re: Pre-Seperations file with collections for output preflighting

Well, for starters, Illustrator only supports one of two possible document colorspaces - RGB or CMYK. If you embed a file into an Illy document then - BOOM! that file is in the document's colorspace:

1) the file is converted from it's colorspace (as denoted by the ICC profile in the image) to the document's colorspace
or
2) the profile is simply stripped

You might be warned, you might not - depends on your colorsettings.

If the color transform occurs - you only have indirect control over it, through your color settings. So, you may not be using the desired rendering intent - black point compensation may, or may not, be used.

Now, you can link the placed files. This avoids unwanted transforms when the files are placed, but creates a logistical problem of managing the image files.

Then think about linking to an image in another colorspace and placing a transparent element (say a drop shadow) over it.

rich

 

[russpears]

Re: Pre-Seperations file with collections for output preflighting

WoW Rich

I did not even think about this issue and I have read a lot on color management. My only reply is that when you set up color management in Bridge for all applications you can set up AdobeRGB as the default color space and this should wrn everyone if they try to change the ICC profile sync. But that is a good one for one few sesigners wory about color management and too many agnore color settings warnings. I have to think about this!! and get back to this topic.

Thanks!!

 

[John W]

Re: Pre-Seperations file with collections for output preflighting

Rich,
You're making some large assumptions here (perhaps rightly so). I feel it is unfair to not qualify your statement that Illy only supports two color spaces.
We place duotones, tritones, dcs2 files and a multitude of spot colors and it works flawlessly. Why? Because we do two very important things; use a separated workflow and do not color manage. We also nearly never embed because if you do and require an extraction for change you lose the extra resolution available from sizing down in the first place (the extracted image comes out at 100% meaning Illy has already downsampled the image when embedding). This can be a definite no-no.
I don't care what the ivory tower guys want us to do because it is bogus on so many fronts while it works on many fronts.
Having said that, once again I want to state that these issues are not for every use nor will they work for any use. I wish everyone is told this over and over but the marketing guy never tells the whole truth and I hate that. BTW, those marketing types hate me at seminars and trade shows!
Thank you,
John W

 

[russpears]

Re: Pre-Seperations file with collections for output preflighting

Rich is talking about the color space thoes duotones, tritones, dcs2 files and spot colors occure in. I am sure you can output any type of color or file as usual, but the ICC profile will allow of better consistancy don't you think? Now printers can do much of this through experiance and never see anything more than a hard proof, but as a designer we need to watch this issue as close as possiable for issue like the one Rich describes.

 

[zgraph]

Re: Pre-Seperations file with collections for output preflighting

Hi Russ,
I'm not Taz Tally but I see no need for a pre-seperated PDF when you can view the seps In Acrobat.
The only thing that I could see them wanting a pre-sep PDF Is so they are not responsable for any problems and they can just say "This Is what we recived." If that Is the case, then that Is a printer I would not want to use.

 

[Andy]

Re: Pre-Seperations file with collections for output preflighting

Although I can understand why some people want pre-separated PS files, there are issues which make them not the best thing to use:

1. You can't trap them as a composite file. This makes the use of any in-RIP trapping a no-no.

2. Performance will suffer, as the job will be intepreted multiple times.

3. (ICC) Color profiles can't be applied (late on) in the job.

4. The actual number of output separations can't be changed (late on in the job). E.g. you can't suddenly decide to make a 5 color job a 4 color job, etc...

5. It's harder to override the screens in a pre-separated job. Although in most cases a (e.g. Harlequin) RIP can (override screens in a pre-separated job), there are cases where there is in-sufficient information in the pre-separated job to determine which separation is being worked on and so the override can end up being incorrect, giving you an incorrect angle and potentially moire. When sending composite jobs, the RIP can fully control / override the screening.

6. Any transparency in the job will have to have been flattened, resulting in a larger job that may not be optimal for a particular output device (e.g. if you decide to change from outputting at 1270 to 2540 or vica-versa).

7. I think there might be other issues, but can't remember them now... too tired after 14 days at Drupa!!

Although the Harelquin RIP for example has a "recombine" mode that will take in pre-seperated data and recombine it into a composite job, there are cases where it's very hard to get right (e.g. Quark traps which change the objects in each separation, or objects omitted from some separations). If the recombine is wrong, then all of the above can be wrong. And not all RIPs support a "recombine" mode.

Unless there are very good reasons for wanting pre-separated PS files and if you have to send PS files (and not application files - which introduce another raft of issues), then composite PS files are better for all the above reasons.

Regards,

Andy.

Andy Cave,
Chief Executive Officer,
Hamillroad Software Limited.
www.firstproof.com
www.hamillroad.com