Which file to use?? You are supplied a print ready pdf AND native documents.

[Jayhawkmike]

This is a question for general commercial printers, although it could apply to anyone reproducing material.

New print project. You receive documents from the client. You do not know the designer. They send you native application documents with all supporting files. They also send a PDF file that conforms to what you would consider "ready for press". You have never had a conversation with this client about what type of file you would receive. Which do you use? Do you call and ask? Suppose the print buyer uses outside source (freelance designer two States away, etc.) and the buyer really doesn't understand/care which you use. They just need to see a proof! ASAP!

I would like to use the PDF file. It checks out great! Designer obviously knew what they were doing when creating and used Instant PDF or preflighted it out of Pitstop, etc. This is the obvious answer for speed and reliability. I drop it in my workflow, trap, impose, proof, and I'm done!

However, what if there is a correction cycle that would dictates you need the native files? Ah, now we have the opportunity to proof the same job with two different files! The InDesign file may not proof the same way as the PDF.

Curious to see if anyone else sees this dilemma and how they resolve it.

 

[mattbeals]

I would process the PDF. But if they then request corrections then I would say that the workflow starts over again because I have to go back to the native file. Making corrections in the PDF if you have the native file available isn't the best idea in my opinion. But if they've got a PDF, it preflights okay then I'd go with the PDF. But isn't the point of the PDF that it is "press ready" copy & content?

 

[162Lehi09]

The ball goes back to their court!

The ball goes back to their court!

Yes, you got the PDF. You produce the proof ASAP. Now they want a correction? Kick the ball back and have their designer do the correction and PDF it direct to you. That's what we do. We do not want to deal with one corrections here or there or have to move paragraphs or elements. That is not our job. If ever we do; we slap them with a whopping bill; they will all go back to their designer who daydreams and designs things in his computer. We are a production shop. We get the PDFs, we put them together and let them fly...full speed. Than to the next job. That's our life. We move paper. Pronto.

 

[melissa]

It is my understanding that when native file and the PDF are supplied that the PDF is the digital equivalent of hard copy as when you use to receive color separated lasers.

We use the native files and then use Prinergy's PDF compare to checked the refined PDF with the customers. Many times the PDF that accompanies the native file is not press quality, and can only be used as a comparison.

Consider yourself fortunate that your customer has the competence to supply you with native file with supporting files and a print ready PDF. These are things I dream about.

 

[almaink]

I would ask call and ask the client if the PDF is current and if so use it. Making small corrections in a PDF isn't an issue and many times is faster than loading fonts and so forth. It is always nice to have the native file tho as line returns and a few other text edits are easier done in native applications.

 

[Jayhawkmike]

My thoughts are in line with the responses so far

My thoughts are in line with the responses so far

I need to make some type of policy when this sort of thing happens so my sales staff/csr/clients are on the same page. They never know what is coming in, the documents just arrive on our FTP site with a PO and quote number!

This is beginning to turn into a trend. With more publishers REQUIRING a pdf file for submission, I'm sure many content creators are supplying PDF files as matter of habit. Thats great!

Where the lines get blurry is when, as mentioned, someone wants to make alterations before press. The buyer is not wanting to send back to design (they charge more $$) and my sales staff wants us to please the client and be the hero and do their "little fixes". Oh my do we do try and keep them happy! Printing isn't exactly doing a booming business - who is?

So, my policy will look something like this.
If preflight says my PDF is good for print, we use it. If not, we use supplied native files.
If corrections require us going back to original native files, we will rework and reproof ALL and charge accordingly.
If corrections can be done by us using Pitstop or Neo, we will proof what is necessary to show changes.

 

[hansman]

Native files without even thinking about it.
We have been burned too many times with PDF files being saved the wrong way.
btw nice avatar
Im an old Scitex guy from the early 90s
Those were the days!

 

[Jayhawkmike]

True, I would agree with native files if I didn't have a handle on my PDF workflow

True, I would agree with native files if I didn't have a handle on my PDF workflow

4 years ago, using the Brisque, I would never have given it a second thought. Native files. End of story.

However, our current workflow and the way we handle PDF files, it just makes more sense IF the PDF supplied checks out under our standards. In fact, it's a much more reliable format and I'm comfortable editing the PDF (if needed) as long as the file is certified. To do this you HAVE to have a good PDF workflow (EskoArtworks Odystar in my case), great PDF editing tools (Pitsop Professional, Neo) and trained folks who know how to use them.

Idea is to have the fewest amount of variables from file submission to proofing. Supplied PDF does that when done correctly. Native files have edit-ability, but more variables. "My text didn't flow like that when I sent it..." I wish to avoid this.

I worked on Scitex equipment when I started this business. Praying Hands of Scitex.

I kind of miss that time. Sound like may parents when I say "...times were slower then." We could expect to generate a page per hour. Now we do an annual report in an hour!

 

[162Lehi09]

yes we do things faster and for what?

yes we do things faster and for what?

while it may be true that we do things faster this time around, they reality is the profit side of the business have slid down. you have people who start to believe that because they could print in their little epsons and hps on their desks they have the right to send you any file or pdf file that was not done right. this just stops the train on its tracks.

and while competition has become stiff and prices have gone down, we keep on investing in better and expensive equiqpment than before. i guess our industry has become almost like a taxi business; the only thing different taxi operators do not bother to lease lexuses anad lincolns to operate their fleet; while we have to invest heavily in software, and modern press equipment. this is our world and as i said earlier; let just keep moving paper. that's the sound of money. my 5 cents.

 

[John Clifford]

PDF files are "normalized" files. IF they have been properly created, then they have the fonts embedded, images embedded, the correct color space for all images, etc.

Native files are for creation. In times past, we had a lot of problems with different fonts on the printer's system than on the creators, each using different versions of software, different Xtenstions or plug-ins, etc. A well created PDF will not be affected by these issues (hopefully created using an ISO standard PDF/X version appropriate for the printer).

As for corrections.

I would NEVER want my printer to make corrections. I want to control my master files (yes, kind of a control freak). If there is another version to be done later, I don't want my file to have an error that might get introduced to the later version. I also want to make sure that someone else doesn't screw up something by "touching" the wrong thing while they're making a correction. If there's going to be a screw up, I want it to be me that has done it. By not sending the printer the PDF file, it ensures that my file is the one that is printed (OK, I know that Pitstop can be used to make corrections as well). As a printer, I'd certainly want the client to fix their files as it's a liability thing.

Having helped develop PDF workflows, I can say that PDF has come a long way. It works really well cross-platform, cross OS, cross application versions, cross font versions, etc.

 

[tobias]

actually this is what PDF+JDF is for. Especially if you have a proper JDF template for your customer designed to answer the questions that may arise in your production process, it is the easiest way to get your complete job defined. And if it's a high-volume job, I would recommend requesting a proof or providing one (digital offset) for the customer to accept.

JDF can provide you with colorspace information, spots, job finishing, addressing, billing information and more. IMO it's one of the most powerful tools available in the industry for job management and it's supported by more and more workflow- and ripsoftwares.

edit: I guess it goes without saying that you need a proper PDF/X from your customer (and thus you will need to make proper pdf/x templates/rulesets).

 

[wetong]

PDF plug-in Enfocus Pitstop well to edit PDF files.

 

[Lukas Engqvist]

I would say as above if PDF is OK use it. I'd probably peak at the original files, just to get to know the customer, and because I'm curious. If they want a change they will have to send a new PDF or I will bounce a PDF for them to approve. EITHER way I may want to do a re-proof and a compare, find that you can get a perfect PDF at first go but the second PDF with just a little change may be wrong because the designer juust had to post a newprint add before making the final change.
New PDF is a New job on simple jobs, perhapps on a book job replacing a page is safer.

 

[waseem563]

anybody know about one time createoutline text in multi pages book in indesign CS2, CS3 by export PDF

 

[couriergraphics]

you might want to repost this as a new thread.