This sounds like the printer did something strange to impose the file and did not use the embedded fonts. Did they offer you a proof before the printing? Did you approve it? Does the job match the proof?
Well, no, they didn't offer proof before printing. I didn't sign anything to approve it. So you think the problem happened on their side when the imposed the file? Therefore, I won't sound silly rushing in their office saying, "Hey guys, what's this job? You did a mistake, please re-print my leaflet!". When you say "something weird", what could it be for example?
You should ALWAYS see a proof before a press run. That's protection for you AND the printer as far as who is responsible when something goes wrong.
Obviously I don't know exactly waht they did, but one possibility is that they put your PDF into Quark Xpress to impose the pages. Before you ask for a reprint, make sure that the PDF prints correctly on your printer. If it doesn't, then the problem is on your end. If you have Acrobat Pro, you should also check the fonts (under dodument properties) to be sure that they are, in fact, all emebedded.
Thanks for your answers, that's very kind. When I visited them, I saw that they were working on CS6. Maybe they didn't impose with the suite, but if they did, could there be problem from Adobe to Adobe? Thanks!
PS : I did check in Acrobat Pro, there are all embedded.
I used to see this frequently in a platemaking dept, we put it down to 2 things: Jobs (even from ID) with text pasted in from MS Word with 'smart quotes' would do this unless you replaced the quotes with proper ones or otherwise there are 2 versions of the font with different encoding (maybe not the correct term) but the same name.
There was also talk of 'screen font' vs 'printer font' with I think only older fonts where some characters did not appear properly when printer font and screen font did not match (they are bundled together in a type1 font), the problem did not show on screen because the missing character in the 'printer font' was not an issue until you output to a postscript device that used the printer font, which is what it is meant to do. Printers many years ago used to install huge numbers of fonts on their RIPs to facilitate output of jobs without embedded fonts and if you had 2 versions (one in the job, one in the RIP) they could have been different character sets or even bodgy modified fonts with the same name.
If the printer's workflow did not use embedded font (unlikely in my experience) then they are in error. If they did use embedded font and the embedded font did not have the character in its 'printer font' then they are not in the wrong except that they should have had their eyes open when printing. You should check a proof but they are becoming rarer these days since improvements in fonts and interpreting them have made a good PDF in a good workflow almost bullet proof.
I offer this opinion with a warning that it is from first hand experiences some years back with no expert knowledge only empirical success. I hope this post might prompt someone with better knowledge to elaborate as I would also like to know a more technical explanation.
Thanks for your answer. What you say is very interesting. Indeed, I pasted the quote from an external application. Therefore (I'm foreign, my english is limited), when making the plate, they might have had the problem then, even with my embedded font? And nowhere in the workflow they had a warning unless they paid an eye on the document? You know the printing world, what can I say to them to have an advantage you reckon? Thanks!
Yes, that is likely to be the issue, the character for 'smart quote' is different somehow from the actual quote symbol. Once again, I stress that I have no technical expertise in this but it was a common failure in the past and changing the quotes in InDesign would fix it. Pasting does not automatically resolve it.
I would go to them and say 'yes I realise there is an issue, but that doesn't mean you can print with your eyes shut', they will have their own philosophy on that and may say too bad. Depends on the circumstances but that problem must be rare these days as I have not seen it in ages so I guess they may be a bit old fashioned in their workflow maybe? Ask them but I would say that it is not your 'fault' or theirs but something unexpected that happened to you both and you can negotiate with them.
You said you checked to see that the font was actually embedded, so we know it isn't retricted. Phil mentions trouble with missing printer fonts in Type 1, but that assumes this is a T1 font. What format is it actually?
Sorry, I was off my computer (night time in my time zone...). Well it's a True Type Collection font with .ttc extension. Do you think it's coming from that?
When you check pdf files for printing it is good to deselect the use of local fonts that will help you to see where glyphs of non-embedded fonts are replaced.
Go to Acrobat:
Mac:Acrobat Pro > Preferences > Page Display > Deselect "Use local fonts"
Win: Edit > Preferences > Page Display > Deselect "Use local fonts"
From Your name I suppose you speak German, so here is the Path in the German Version:
Mac:Acrobat Pro > Voreinstellungen > Seitenanzeige > Wähle die Option "Lokale Schriften verwenden" ab
Win: Edit > Voreinstellungen > Seitenanzeige > Wähle die Option "Lokale Schriften verwenden" ab
Thanks for your answer. I deselected and I can still the quotes marks correctly.
Maybe it's because it"s a .ttc? Any issue with .ttc ? Thanks!
It would be interesting to know how the printer is postprocessing your file?
I have heart from several sources that these things happen when a font is not embedded completely. In the PDF Export settings go to Advanced (Erweitert) and give a low value (1%) for subsetting fonts.
Maybe it's because it"s a .ttc? Any issue with .ttc ? Thanks!
No problems that I've heard of.
Unfortunately, I haven't been able to respond to this thread up until now, but having reviewed this full thread, I have a few comments to offer:
It is irrelevant whether the original text was copied and pasted or whether the font was Type 1, TrueType, a TrueType collection, OpenType CFF, etc. The real issue is whether the PDF/X-3:2002 file exported from InDesign is indeed valid. This can very easily be verified by running the appropriate preflight profile for PDF/X-3:2002 in Acrobat Pro 10 or 11. There is no need for any third party plug-ins or any other software for this.
Assuming that preflight pronounces the file to be 100% kosher with no exceptions and that the file displays properly in Acrobat Pro, you should then try printing the file (or even just the pages that exhibited the problem) from Acrobat Pro to a printer that supports Adobe PostScript 3.
If the printed output from the PostScript printer is correct as well, the problem lies totally with your print service provider and their workflow.
In our extensive experience, problems can occur in any number of ways. One of most frequent sources of problems are printers who routinely open PDF files in Adobe Illustrator to view and “fix” them, somehow thinking that Adobe Illustrator is a general purpose PDF editor. For the record, Adobe Illustrator is not, repeat not, repeat yet again not a general purpose PDF file editor. Adobe Illustrator can only successfully edit PDF files saved from Adobe Illustrator itself when the “save editability” option is specified. Even then, Illustrator requires you to have all fonts referenced by the PDF file actually installed on your system; it does not use any fonts embedded in the PDF file. For other PDF files (such as those produced by Distiller, export from InDesign, etc.), character substitutions (especially for non-ASCII characters such as typographical quotes), font substitutions, color space changes, etc. are common issues.
If the printer is not abusing Illustrator on your InDesign-exported files, it could be any number of third party products that many printers use, some of which are of dubious value and some of which may be either defective in terms of compliance with the PDF specification or simply grossly out-of-date. (It is amazing how many print service providers put their customers' submitted PDF files through all sorts of “fixup” processes, regardless of whether the files need such fixups or not. Many of these “fixups” are more likely to cause problems than they are to fix anything!)
Under no conditions should you need to fully embed fonts in your PDF files. Certainly no Adobe software, including applications, Acrobat, and our PostScript and PDF RIP technologies licensed to OEMs is any way sensitive to whether fonts are subsetted or not! If a third party workflow component is so-sensitive, it is by definitiion defective.
In terms of imposition, there should likewise be no sensitivity to whether fonts are subsetted or not. By the way, the most reliable imposition is actually done at the RIP itself, not by programs that either place PDF files into other documents and regenerate PDF or by utilities that rearrange PDF files or create new PDF files representing the printed flats.
This thread also discussed the issue of whether the OP received a “proof.” Unless you receive a hard copy proof in which the content was put through the exact same workflow as the final product, including RIP and all prepress steps, it is very possible that the defect noted would not show up on the proof. Nonetheless, obtaining a hard copy proof is an excellent idea, especially if the issue comes up about liability for the cost of reprinting the job or even whether the original job should be paid for if the print service provider can't “fix” their workflow problems!
Thanks Dov, I have read your opinion on Illustrator many times, but users are still doing it (including me) especially since clicking on an object in Acrobat for editing routinely offers Illustrator as an editing option. I doubt this is the case here.
I think in this case I would like you to comment please on my observation (seen many times) that if text is copy/pasted from Word to InDesign with 'smart quotes', this may fool the RIP. I presume this happens in fonts that are present in RIP substituting for embedded fonts but my strong suspicion is that even when embedded, the character may still fail if the RIP does not process the 'smart quote' scenario successfully. I am unclear as to whether the problem is because the character does not get 'set' in postscript version but only in screen version or if it uses a character code that is not valid (or not subsetted) in the RIPped file.