I recently helped a new author self-publish her first novel, which went fine until we uploaded the manuscript to CreateSpace and printed a physical copy to take a look at. We used a number of fonts in the document, but one of them refused to embed, even though we’d told Microsoft Word to embed all fonts. In spite of this, the PDF looked fine in their on-line preview tool, and the digital proof they emailed us showed a document that looked ok too. Unfortunately, when we received the printed book, we discovered that any page containing the font in question was printed at about half the darkness as the other pages, and it seemed a little rougher and more pixelated too, especially on characters like em-dashes. (Even though the font was only one or two characters on an entire page of otherwise normal text!) We had to fix this, but their tech support was utterly useless, so after some poking around and experimentation, we found the solution ourselves…
The only indication that we might have a problem with the final printed version was from a rather cryptic warning from CreateSpace that there were two “non-blocking issues” with our file:
- “The interior contains images that are less than 200 DPI.”
- “The interior contains transparency which is flattened during our processing and may result in a slight change in appearance.”
Since there’s only one image in the book which didn’t need to be high res, we didn’t care if it had a low DPI, and since it was a full-color JPEG image, the bit about transparencies just didn’t make a whole lot of sense. And in any case, why should flattening an image’s layers of transparency impact the text elsewhere on the page? We sent them an email asking what to do about characters that were supposed to be fonts instead of images, but were told to just order a proof to see how it looks actually printed. So, since it looked fine to us, we went ahead and printed a copy, and were disappointed at the results.
When email became too cumbersome to use for an intelligent conversation with CreateSpace’s tech support about this odd printing issue, we called them instead, but it quickly became clear that their phone support was no better option. The representative was not a native speaker of English and it was difficult to speak about this issue without a lot of frustration for both of us. Also, she never looked at the files, so she had no idea what they looked like. She just told us to provide the information requested in the follow-up email (to which they never responded). She seemed completely disinterested in trying to solve the problem over the phone or transferring us to someone else who might have been better suited. We were flummoxed over the representative’s inability to help in any way other than to tell us to send a response to the email from Customer Support (which we did, and got us nowhere).
So we got more serious about solving this without help. Luckily, we’d noticed that one of the fonts we were using wasn’t listed as an embedded font when we viewed the PDF’s properties, even though Word gave us no warnings or errors of any kind when creating the file, and we knew the font was capable of being embedded. (It was a dingbat-type font used to separate breaks within a chapter.) Then we discovered that you could run a “flattener preview” tool in Adobe Acrobat’s Advanced->Print Production menu. When we were on a page containing the non-embedded font, the flattener preview tool allowed us to highlight the affected characters needing transparencies. Sure enough, it always highlighted the characters created from that font. When we went to a different page with all normal text, it highlighted nothing. Additionally, running the “Preflight” tool in that same menu got Acrobat to check the entire document for errors and sure enough, it listed fonts, transparencies, and low dpi images as problems.
Then I remembered that this particular font was an OpenType font (OTF) while the other fonts were all TrueType fonts (TTF). Considering OTF files are improved versions of TTFs, with roots in Microsoft and Adobe, you’d think there would be no problem at all working with them in Microsoft Word and Adobe Acrobat – but you’d be wrong!! As it turns out, all we had to do was download the TTF version of our font and install that on our system, replacing the OTF version. Now, when we opened the Word doc, it looked the same, but when we did a “Save As PDF” and told it to embed all fonts, this time it included our previously missing font!
Sure enough, Acrobat now no longer reported those errors in the Preflight tool, and the Flattener Preview tool also never showed any transparencies where it did before. We sent this updated file to CreateSpace and now the final physical copy looks great! Problem solved! All we had to do was replace the OTF font with a TTF version of the font! Hopefully this info will help you avoid the same headaches in your own publishing endeavors.
Incidentally, I was curious what would’ve happened if I didn’t have access to a TTF version of my font, and it does appear there’s another option. While I always strongly recommend that people create PDFs from Word files using Word’s built-in “Save As” PDF file type option (a new feature since 2010) because it ensures everything will look as close as possible to what you expected, you can still “Print to PDF” just like we did years ago, when that was the only way to make a file into a PDF. Though this can sometimes cause alignment issues and other oddities with the more advanced features of Word, like embedded graphs, etc., for most books this isn’t a problem. The nice thing about the Print to PDF option is you can go into the “Printer” settings and tell it to embed fonts there, instead of relying on Word’s checkbox to embed all fonts in the “Save As” options to do it. Sure enough, when I tried doing this, it DID embed my OTF font. However, I’d already moved forward using the document with the TTF font instead, so I can’t say for sure whether this would’ve solved the CreateSpace printing problem equally as well – though it certainly looks like it would. If you’ve ever tried this, please leave a comment below!
Addendum:
We got one last follow-up email from CreateSpace about this, after we’d already received the book and seen the problem was fixed. They acknowledged that the new book was shipped and looked like it should be fine now, and then went on to say the following, FWIW:
I can only speculate on a cause of the text pixelation issue in the physical proof the Member received.
From reviewing the current file, they believe that you had most likely corrected the issue. The previous file review for the interior dated 11/19 noted that transparencies in the file had been flattened. Because you had noted the pixelation problem was only on the pages with the fleuron, most likely the fleurons were RGB images that forced the text to be in the same RGB color space, contributing to gray, pixelated output. This would have been very noticeable in the very thin, handwritten font.
In the current file, the fleurons were 0% and processed to 100% black CMYK with no transparencies present, so they believe the interior should print fine at this point.