Copy link to clipboard
Copied
Hi Everyone,
Came across an issue yesterday that might help others. I was saving a large PDF (238MG) as a reduced size PDF. The body text font was Century Gothic. We have used this font for a client for a few years now, so nothing new there. Also nothing new with our processes. This is an everyday workflow procedure to us. When I saved it as a reduced size file for client viewing, Century Gothic (regular) become corrupted. By corrupted I mean it defaulted to another font and did not display as Century Gothic. After a couple of hours of trouble shooting the font and other issues it could have possibly been with my system, I figured it out.
If you instead go to File, Save As..., Optimized PDF, select the Font tab, then select the "Do not unembed any fonts" checkbox. I noticed that Century Gothic was in the box as "unembed fonts."
After selecting this feature, I tested it and it worked. Voila! Hope that helps anyone else. We just recently updated Creative Cloud, so might have something to do with it. Or it could be other system updates that were run. Either way, found a work-around, and wanted to pass along.
Thanks,
Amberle
Copy link to clipboard
Copied
Amberle,
Thanks for posting this.
“Everyone” knows that font is a four letter word beginning with an ‘f’. If we had to do it all over again, it is likely that PDF would never have allowed “fonts by reference,” i.e. unembedded fonts that rely on the recipient having the same font installed on their system or lacking that, using a “substitution font.” In both cases, it is possible that the original font had an unusual encoding or that text referencing said font had an unusual encoding. Alternatively, the font used and embedded in the original PDF file may have had many more or different glyph definitions than that on the system on which a PDF without the font embedded is being viewed on. And this is a real problem!
For example, the current version of Arial on the latest version of Windows 10 has support for 4503 glyphs. The version of Arial on Windows 7 has support for 3421 glyph definitions.
This is exactly why Adobe recommends that PDF files be created with all fonts subset embedded and that fonts that are embedded not be unembedded to save a few KB of PDF file size. All the ISO PDF subset standards (PDF/X, PDF/A, etc.) require that all fonts be embedded (at least subset embedded) to avoid the problems you encountered.
- Dov
PS: The “large PDF file” you refer to – what application(s) actually created it?
Copy link to clipboard
Copied
Amberle,
Thanks for posting this.
“Everyone” knows that font is a four letter word beginning with an ‘f’. If we had to do it all over again, it is likely that PDF would never have allowed “fonts by reference,” i.e. unembedded fonts that rely on the recipient having the same font installed on their system or lacking that, using a “substitution font.” In both cases, it is possible that the original font had an unusual encoding or that text referencing said font had an unusual encoding. Alternatively, the font used and embedded in the original PDF file may have had many more or different glyph definitions than that on the system on which a PDF without the font embedded is being viewed on. And this is a real problem!
For example, the current version of Arial on the latest version of Windows 10 has support for 4503 glyphs. The version of Arial on Windows 7 has support for 3421 glyph definitions.
This is exactly why Adobe recommends that PDF files be created with all fonts subset embedded and that fonts that are embedded not be unembedded to save a few KB of PDF file size. All the ISO PDF subset standards (PDF/X, PDF/A, etc.) require that all fonts be embedded (at least subset embedded) to avoid the problems you encountered.
- Dov
PS: The “large PDF file” you refer to – what application(s) actually created it?
Copy link to clipboard
Copied
Thanks Dov, that made a lot of sense. To expand on our procedures and to answer your question, this is a large PDF file exported from Microsoft Word. The Word document contains text and images that we then pull into InDesign and add our graphics. Prior to running the script that lays the pdf out in Indesign, we edit (colorize) the font and various elements using Pitstop Pro.
What was different in this instance that could have caused the issue, was we edited the PDF in Pitstop PRIOR to laying it out in InDesgin. In the past we would lay it out in InDesign and then colorize in Pitstop Pro. Could have have played a role? In our trouble-shooting, we did export the PDF prior to colorizing in Pitstop Pro and it did not produce the issue. Hmmm. So maybe?
Either way thank you for your prompt response. The supported glyphs is definitely understandable as we are also working on different systems that house different programs throughout the process previously explained. Pitstop Pro is on one system supported by one operating system, whereas InDesign is housed on another system with a different operating system. Both with the same version of Century Gothic.
Thanks again!
Amberle
Copy link to clipboard
Copied
Pitstop is generally very reliable software. Unless you were doing something in Pitstop that somehow mucked with the fonts and their encoding, I strongly doubt that Pitshop is the source of the problem.
That having been said, the less mucking around you do with PDF files after they are produced, the more reliable your workflow is bound to be. For example, you would be much better off doing whatever colorizing you are doing prior to placing assets into InDesign and exporting PDF than coloring after-the-fact using Pitshop or anything else. PDF really works best as a Final Form File Format.
- Dov
Find more inspiration, events, and resources on the new Adobe Community
Explore Now