Fonts displaying correctly but printing incorrectly

[cbordey]

Hello,

I recently sent a pdf to a printer. I reviewed the pdf and it was fine, however when I received the book, all of the fonts that were headers turned out strangely. I was told to save the file as pdf/x so that it embeds the fonts. My question is which pdf/x do i use as publisher has pdf/x-1 and pdf/x-3. There's also a pdf(flatten) which seems like it would work too. Attached is the font issue. The font is Lato.

 

Thanks!

[Andy05]

Sorry, that's not helpful in your case (as it's not useful in your publication)—but that's a fancy looking effect which happened there. I'm sure quite some designers, who do e. g. posters or flyers would like to have an easy way to produce such "glitch" on purpose.

[lacerto]

This looks like a combination of an OpenType feature badly misfired + some odd problem with confused font installation + malformed outlines something which I have sometimes seen when applying e.g. pressure on font stroke. Did printer have any explanation?

Can you load here on the forum e.g. one page (e.g. p. 14) of the Publisher document just to see what kinds of font attributes and styles are involved?

UPDATE: As for your question about PDF/X modes, there are three different available in Affinity apps, and they all allow the user to change the default font embedding policy which is embedding only the sub set of fonts that are used in the document (that is, the exact characters that are used in the text that uses each specific font). If something goes wrong with this, it at least theoretically could show as something that has happened here, replacing the missing glyphs with ones from other fonts, but that should show already in the exported PDF and not just at the time the job is processed for printing. But removing the check mark from the "Subset fonts" option under the "More" settings of the PDF Export dialog box might be worth a try to see if it fixes the problem (as that option embeds the entire font disregarding which characters the text uses). The export method will stay "PDF/X"-based even if the option of sub setting is not used.

The "flatten" export method would rasterize all text and would naturally be fool-proof method to ensure that text is rendered correctly but would produce huge file sizes and less than ideal quality.

One further option would be converting the problem texts (headings) to curves, but that is probably not a good idea, either, if you also plan to publish a digital version of your book, as you'd probably want to keep text as text in the digital version. You can also force fonts to be converted to curves using a PDF export option, but that would also mean that the print file can become very large, and depending on printing method, might also produce a bit worse print quality. But it would allow you to keep text as text in the document so that you can produce a digital version where all text is kept as text.

[cbordey]

Here's a screenshot of the character properties and the .afpubj file.

 

AOB temp.afpub

[kenmcd]

Which version of the Lato fonts are you using?
The old version from Google fonts?
Or the newer version from the author's website?

I exported your test doc to PDF without any issues (using the newer version).

Also make sure you only have one version installed.

EDIT: After thinking about this and re-reading your original post the disconnect has to happen at the printer. It is their printer postscript engine which is creating the page. Sometimes on some printers the old postscript code in them can do some odd things especially when converting from TrueType fonts to the postscript code they actually send to the rasterizer. You could test this by converting the Lato fonts from OpenType-TT (TTF) to OpenType-PS (OTF). I can convert the fonts for you if you want to try this.

Edit (takes just a few minutes to convert): Lato.v2.015.converted.to.OpenType-PS.(OTF).zip

[lacerto]

I had a look on the extract you posted and could not find anything that could explain this. It would be interesting to have a look on e.g. p.14 extracted from the actual production PDF, if you still have that, just to see how exactly it was exported.

I had one possible explanation for this, assuming that a variable version of a font might have been used instead of static, but it seems Lato only comes as static versions (as for Lora, it includes also variable versions in the same package). In theory, if using Affinity Publisher on macOS, it would be possible to use the variable versions even if Affinity apps do not have full support for them (the glyphs are rendered correctly but use wrong metrics). That (or having installed both variable and static versions of a font) could cause surprises when exporting to PDF, even if everything appears to be fine when viewing the file, and even if the actual problem is caused by another font than one that shows the problems (as using Lora variable version but having problems with Lato static version). But based on tests with static and variable versions of Lora, it does not appear that this could have happened.

I also produced PS and PRN (HP-PCL XL) print files destined to a pretty old PostScript device (Dell 3130cn) from a PDF produced from the Publisher document with standard print settings that embed sub sets of fonts, and there were no problems with the fonts with either print file when distilled to PDF or rendered using a PCL viewer [I am currently out of office and could not send the file directly to the printer]. 

I used Google OpenType (TrueType flavor) versions of the fonts. 

Based on these tests there does not seem to be room for other explanations than ones that assume that something went wrong because of the print technology used, so I would try to resolve the problem with the printer. It may well be that not allowing subsetting, or producing the print file e.g. using a specific method (e.g. PDF/X-1a:2003) could resolve this -- or using the PostScript flavor of the font created by @LibreTraining in the post above -- but there is really nothing special about the original document nor in the resources it uses that could explain the error. That a commercial printer would use technology that cannot handle Google fonts, seems really odd, but when other possible causes do not seem to explain the error, it is a well-based hypothesis.

[Alfred]

22 minutes ago, Lagarto said:

That a commercial printer would use technology that cannot handle Google fonts, seems really odd, but when other possible causes do not seem to explain the error, it is a well-based hypothesis.

As Sherlock Holmes famously observed: when you have eliminated the impossible, whatever remains, however improbable, must be the truth.

[kenmcd]

1 hour ago, Lagarto said:

That a commercial printer would use technology that cannot handle Google fonts, seems really odd, but when other possible causes do not seem to explain the error, it is a well-based hypothesis.

The most common hard-to-explain issue seen with commercial printers related to fonts is the use of components in OpenType-TT (TTF) fonts. In some cases the PostScript code used in the printers is very old and it does not properly handle components when converting TrueType outlines to PostScript (in OpenType-PS fonts do not use components). But in that case what we see in the output is decomposed glyphs - not the strange letters we see here. 

The most common issue when the wrong fonts in appear in a PDF is the PostScript name is messed-up in the fonts (or duplicate fonts are installed). But that is going to show up when the Export to PDF is done. If the fonts appear to be OK, because the Export to PDF is OK, then something must be happening at the printer. Soooo I took my best WAG... and it is relatively easy to try the OpenType-PS (OTF) fonts.

Since we have no obvious answer, as it all seems normal in the doc, it has to be something at the printer. And I (we) have never seen that kind of distorted output before so it is most likely something weird.

Note: the composites-in-TTF-fonts-at-some-printers issue affects all OpenType-TT (TTF) fonts, not just those from Google Fonts.

[lacerto]

4 minutes ago, LibreTraining said:

Note: the composites-in-TTF-fonts-at-some-printers issue affects all OpenType-TT (TTF) fonts, not just those from Google Fonts.

Yes, I was referring Google much because I suppose that all their fonts use OpenType TTF flavor, and because they are free and popular, so these kinds of problems would then likely to be something that the printer has come across in other print jobs. Many of Google fonts appear to have high quality (e.g. Lato), but I have no expertise to really judge that, but precisely because of their popularily I'd be surprised if any possible gilches were not quickly fixed. Therefore checking for possible updates would also be a good idea when trying to troubleshoot these kinds of issues.

[PaulEC]

2 hours ago, Alfred said:

That a commercial printer would use technology that cannot handle Google fonts, seems really odd, but when other possible causes do not seem to explain the error, it is a well-based hypothesis.

Well there have been other people here who use printers who will only accept png files and not pdf, so nothing would surprise me!😕

[lacerto]

24 minutes ago, PaulEC said:

Well there have been other people here who use printers who will only accept png files and not pdf, so nothing would surprise me!😕

This does not appear to be comparable to such print jobs, so even if this particular printer were rather small, they seem to have printed several books commercially, which means printing in PostScript based technology (from PDFs). PNGs are raster graphics, so fonts could not even theoretically be a print issue there.

[iconoclast]

I would suppose that the Lato font is only substituted by some reason by a verry crazy decorative font. What the Font didn't find a font that fits to it, as I tried it some minutes ago, but if you compare the single letters that appear repeatedly in the text, they are congruent to each other. So it is possibly not a sort of distortion, but a special font that replaced the Lato in print.

[lacerto]

52 minutes ago, iconoclast said:

So it is possibly not a sort of distortion, but a special font that replaced the Lato in print.

It is possible but I think it is unlikely, though. Look e.g. how number 6 is malformed. Even in most exotic glyph forms, I'd imagine that there should be more recognizability to the "standard" (as there is with most other glyphs shown here). I suppose that the glyphs, even when rasterized incorrectly, would be consistent as once generated, they are just referred to, so they do not fail when they are drawn (repeatedly), but when they have been rasterized.

UPDATE: There is something similar here as reported on the Glyphs forum:

https://forum.glyphsapp.com/t/deformed-glyphs-when-printing-highly-complex-font/12105

[kenmcd]

4 hours ago, iconoclast said:

I would suppose that the Lato font is only substituted by some reason by a verry crazy decorative font. What the Font didn't find a font that fits to it, as I tried it some minutes ago, but if you compare the single letters that appear repeatedly in the text, they are congruent to each other. So it is possibly not a sort of distortion, but a special font that replaced the Lato in print.

That is a great observation.
That is the kind of thing that happens in Export to PDF when there is a corrupted font cache.
Of if the PostScript Name is not correct in the font family.
The PostScript Names look OK in the Lato from Google Fonts, and from the author.
Gotta find that font.

Could the printer have a corrupted font cache?

@cbordey Could you please attach a PDF you have created - so we check the PostScript Name on the embedded fonts.
And/or check the PDF you sent to the printer to be sure the embedded font names are correct.

[kenmcd]

7 hours ago, Lagarto said:

Many of Google fonts appear to have high quality (e.g. Lato), but I have no expertise to really judge that, but precisely because of their popularily I'd be surprised if any possible gilches were not quickly fixed.

There are many high quality fonts in Google Fonts (GF).
BUT, there are also many fonts in GF which have issues, and have not been fixed.
When GF first started they loaded up all the FOSS fonts they could find.
And some of those were not too good, and some of those issues remain today.
For example the Prompt font family.
It was bad the day the developer uploaded it to GitHub.
It was bad the day it was added to Google Fonts.
And it is exactly the same if you download it from GF today (or the GitHub repo).

Lato from GF (today) - v1.104 (2011), 5 weights, 10 styles, 275 glyphs, 4 OpenType features
Lato from the author - v2.015 (2015), 9 weights, 18 styles, 3,023 glyphs, 25 OpenType features
I have no idea why GF has not updated the fonts, and neither does the author.

The GF team is relatively small and they deal with thousands of fonts.
It can be a daunting task, which they are working hard to automate and improve.
Their font testing tool FontBakery is updated, expanded, improved, etc. almost daily.
Fonts that were added in the past would not make it thru the FontBakery quality check today.

Very few of the fonts are actually developed by members of the GF team (increasing tho).
Most are from what they call the "upstream repo" - the repository of the actual developer.
Occasionally GF will commission people to expand or improve fonts, but that is not very common.
Sometimes the error is upstream.
Sometimes GF just screws-up.
The IBM Plex family finally just got updated in GF - they were over a year behind the upstream repo.
Stuff falls thru the cracks.
A GF guru posted an interpolation issue on a font the other day.
I replied that it had been fixed in the source repo months ago.
They could not figure-out what happened, but it is being updated now.

Sometimes there are unfixed issues in the upstream repo.
Earlier this week I posted 25 glyph interpolation issues in the current Inter fonts.
And these are fantastic well made fonts! Just very complex. Stuff-happens.
Those issues are also present in the static fonts that GF supplies today.
Note: Inter is the default font in this forum - so you may be looking at it right now

I could go on and on with the GF war stories.
They are working hard and getting better and better every day.
But users are going to continue to run into issues with some GF fonts for the foreseeable future.
A lot of great FOSS fonts, and some not-so-great FOSS fonts.

If you want to get an idea of the GF daily insanity, take a look at their Traffic Jam.
https://github.com/google/fonts/projects/1

 

[lacerto]

1 hour ago, LibreTraining said:

Lato from GF (today) - v1.104 (2011), 5 weights, 10 styles, 275 glyphs, 4 OpenType features
Lato from the author - v2.015 (2015), 9 weights, 18 styles, 3,023 glyphs, 25 OpenType features

Oh yes. I ran my print tests on a PDF created on macOS where I had installed the GF versions, but I now reran it on Windows where I had the much more complex 2.015 versions installed. I suppose the glitch might happen more easily with these versions, and I tested this both with sub set and full embedding, but I could not create any problems either way. The 2.015 versions have this additional info included in legal stuff:

"In 2013-2014, the family was greatly extended (with the help of Adam Twardoch and Botio Nikoltchev) to cover 3000+ glyphs over nine weights with italics. It now supports 100+ Latin-based languages, 50+ Cyrillic-based languages as well as Greek and IPA phonetics."

So there is no expertise lacking in construction of this particular font that now has been treated this crazy way in this print job! 

[kenmcd]

59 minutes ago, Lagarto said:

So there is no expertise lacking in construction of this particular font that now has been treated this crazy way in this print job! 

Lato is a really nice font. It was my default headings font for a long time.
Only recently changed because I needed slashed zero in headings (and wanted optical sizes).
Highly unlikely any of this is caused by the Lato font(s).

[cbordey]

Thanks for the info and responses everyone. Attached are a couple pages from the exact pdf I sent to the printers. I exported my file using "pdf for print." I sent it to thebookpatch.com. I send my stuff there prior to KDP as I can get a proof back quicker. 

I printed the file myself and there were no issues, so I'm thinking it has to be their printer. I brought it to their attention and they said "Since we use digital printers they can be quite sensitive, especially if the font used is a specialized kind. That is why all the titles are printed that way." They recommended I export as pdf/x. Hoping that will fix the issue.

I downloaded the font from Google fonts. Not sure if it makes a difference but I use Fontbase to manage my fonts.

 

 

aob temp 2.pdf

[lacerto]

5 hours ago, cbordey said:

I exported my file using "pdf for print." I sent it to thebookpatch.com

Their recommendation seems to be using PDF/X-1a:

https://www.thebookpatch.com/wp-content/uploads/pdfs/howto/ConvertInDesignToPdf.pdf

...which basically means a lean and mean PDF where all colors are converted to CMYK and possible transparencies have been flattened. The file you sent does not essentially differ from it even if it uses later PDF version (PDF 1.7 instead of PDF 1.4). Both versions use subsetting when embedding fonts. It is a good idea to use this preset as it is recommended, but it seems odd that this could really make a difference (to avoid problems with fonts).

As there is nothing special about the font (Lato) -- the Google version is much simpler than the later author version --  and it is a professional font, I do not think that there is any other explanation for this than a problem with the printer (e.g. corrupt font cache, something that would most probably get fixed by "turning off and on again"). 

[kenmcd]

14 hours ago, cbordey said:

I brought it to their attention and they said "Since we use digital printers they can be quite sensitive, especially if the font used is a specialized kind. That is why all the titles are printed that way."

That is just silly, Lato is a well made totally plain vanilla font.

14 hours ago, cbordey said:

Attached are a couple pages from the exact pdf I sent to the printers.

I looked at the PDF and the font names are just fine.

It appears the issue is at their end.
Perhaps there is a conflict with some font they have installed.
We could change the name of Lato so it would definitely be unique.
And even get around some weird font cache issue.
I could change it to something like Lato4abb and output to OTF files.
May work.
Let me know if you want to try that.
Or you could just wait a little longer for a KDP test - which will probably work fine.

[cbordey]

@LibreTrainingThanks! I'm going to send to KDP for a test print, should work out fine *fingers crossed*