Character inconsistency in printing fonts

[Bill Ward]

Is anyone familiar with an issue of fonts printing inconsistently? Here's the issue - I receive a PDF from the customer. Everything looks fine but when I go to print, some of the characters are bold and others are not. You can't see if on the screen and it's not even consistent throughout the document (for example, some "e"s get bolded while others don't). One designer I spoke to thinks it the printer (the Fiery in this case) but I'm more inclined to think it's how the PDF was created.

 

[SoggyWinter]

try converting fonts to outlines in Acrobat and see if it rips+prints differently.

 

[Dov Isaacs]

@Bill Ward - You say that “everything looks fine” in the PDF file you received from the customer. Exactly what do you mean by “everything looks fine?” Is the PDF file a PDF/X-4 file? Did you validate that all fonts referenced in the PDF file are in fact embedded? Did you run Acrobat Preflight against the file, specifically looking for whether all fonts are embedded? Just because a PDF file “looks fine” on the screen (and I assume you are referring to viewing the file in Adobe Acrobat), it doesn't necessarily mean that at least, in terms of fonts, that everything is indeed “fine.” If a font used by text in the PDF file is not embedded, if that font is at least installed on your system, Acrobat will render the text using the font installed on your system – such fonts are not necessarily (nor likely) installed on your printer / RIP / DFE.

If in fact Acrobat Preflight indicates that a particular font (or part of a font) is not embedded, you can use Acrobat Preflight to embed that font such that it does print correctly.

Although @SoggyWinter does provide a “solution” that may work, the problem with converting fonts to outlines often results in overly bold-looking text and/or distortions in fine details, especially for smaller point sizes, lower resolutions, and/or highly-detailed fonts.

Going forward, you should always insist on PDF/X files (preferably PDF/X-4) or if the content is coming from non-graphic arts-based applications such as Microsoft Office, the PDF files should be created with options that embed the fonts. (Note that the Save as PDF feature of Microsoft Office as opposed to the Adobe Save as PDF feature that is available as part of Adobe Acrobat is known to have significant problems with embedding fonts that aren't TrueType-based fonts!!

- Dov

 

[xmoles]

Hi

Have you checked that they do not have any stroke applied?

 

[Bill Ward]

@Bill Ward - You say that “everything looks fine” in the PDF file you received from the customer. Exactly what do you mean by “everything looks fine?” Is the PDF file a PDF/X-4 file? Did you validate that all fonts referenced in the PDF file are in fact embedded? Did you run Acrobat Preflight against the file, specifically looking for whether all fonts are embedded? Just because a PDF file “looks fine” on the screen (and I assume you are referring to viewing the file in Adobe Acrobat), it doesn't necessarily mean that at least, in terms of fonts, that everything is indeed “fine.” If a font used by text in the PDF file is not embedded, if that font is at least installed on your system, Acrobat will render the text using the font installed on your system – such fonts are not necessarily (nor likely) installed on your printer / RIP / DFE.

If in fact Acrobat Preflight indicates that a particular font (or part of a font) is not embedded, you can use Acrobat Preflight to embed that font such that it does print correctly.

Although @SoggyWinter does provide a “solution” that may work, the problem with converting fonts to outlines often results in overly bold-looking text and/or distortions in fine details, especially for smaller point sizes, lower resolutions, and/or highly-detailed fonts.

Going forward, you should always insist on PDF/X files (preferably PDF/X-4) or if the content is coming from non-graphic arts-based applications such as Microsoft Office, the PDF files should be created with options that embed the fonts. (Note that the Save as PDF feature of Microsoft Office as opposed to the Adobe Save as PDF feature that is available as part of Adobe Acrobat is known to have significant problems with embedding fonts that aren't TrueType-based fonts!!

- Dov

Thaks for chiming in Dov, I was hoping you would. I also understand the risks of saying "everything looked fine" in a forum of this caliber, lol. I did not run Acrobat Preflight against the file and in a perfect world I always would. We are fortunate enough to have relatively few baffling issues when printing customer files (they're usually the garden variety -missing bleeds, RBG files, etc) This particular issue creeps in so infrequently (surprisingly) that we've never nailed down the cause. We assumed it was an embedded font/PDF issue but there are some strange inconsistencies that made us wonder. In this case for instance, the customer provided us six PDFs for six different business cards and the "printing bold characters" issue occurred on all but one of the six cards. For some reason, one printed fine even though they (seemingly) used the same fonts across all of the cards. I know converting to outlines can be a satisfactory workaround some of the time, but I usually like to understand what is causing the issue. We even considered whether it was a Mac>PC issue since most of our customers are Mac based and we are a PC based print shop. Thanks for your reply.

 

[Bill Ward]

Hi

Have you checked that they do not have any stroke applied?

They do not have one applied. I assume it is related to embedded fonts (or lack of) and the PDF creation.

 

[Dov Isaacs]

Thanks for chiming in Dov,
…

We even considered whether it was a Mac>PC issue since most of our customers are Mac based and we are a PC based print shop.

In my many years in dealing with these issues, I recall very, very few instances in which there was really a Mac->PC issue, although many of those who worship at the alter of St. Steve-the-Infallible would like to believe that. An embedded font is an embedded font. A font is either fully-embedded in which case all the possible glyphs in a font are available for the RIP process or is subset-embedded in which case only the glyphs referenced by the existing text are embedded (the benefit being a potentially significant PDF file size reduction). That having been said, if a PDF file is created on one platform with fonts subset-embedded and is then edited (let's say in Acrobat) using glyphs that weren't previously embedded, but are resident on the system, those additional glyph definitions are probably not being subsequently embedded into the PDF and thus, might be rendered via the RIP's “substitution font.”

Without seeing the PDF file in question, I can't give a more definitive response. Sorry!

- Dov

BTW, for what it is worth, I always considered Font as a four letter word beginning with an F …