# How to ensure that LaTeX-generated pdfs print correctly from print-on-demand services

I've just bought printed copies of a pdf-booklet I've made using luaLaTeX. The "print ready copy" created during the Lulu upload process looks fine in the electronic version and when printed on my local printer. However, the printed copies from Lulu lack some characters from one of the fonts used in the document.

The document is typeset in Biolinum with a couple of symbols from MarVoSym and FontAwesome and a couple of characters from Computer Modern. The font-information extracted using pdffonts on the "print ready copy" from Lulu indicates that all fonts are embedded and subsetted:

name                                 type              emb sub uni object ID
------------------------------------ ----------------- --- --- --- ---------
QNTGDG+LinBiolinumO                  CID Type 0C       yes yes yes      9  0
YCZZZO+LinBiolinumOB                 CID Type 0C       yes yes yes     16  0
TIILYD+LinBiolinumOI                 CID Type 0C       yes yes yes     32  0
NJDZPD+MarVoSym                      Type 1            yes yes no      39  0
ZRZEPL+FontAwesome                   CID Type 0C       yes yes yes     43  0
KVFQUZ+CMSY8                         Type 1            yes yes no      71  0
YGYBQB+CMMI8                         Type 1            yes yes no      75  0
TXCQMU+LinBiolinumOBO                CID Type 0C       yes yes yes    106  0


The missing characters are from FontAwesome. Specifically, the two used symbols from FontAwesome are InfoSign (U+F05A) and ExclamationSign (U+F06A). These symbols are the only two symbols used from FontAwesome and were inserted in the document using the \faInfoSign and \faExclamationSign commands from the fontawesome package. Can I do something from the LaTeX-end to ensure that all fonts in my pdf will show up in the printed copy?

Some forum posts on the Lulu.com site indicate that fonts must not only be embedded as a subset but rather be fully embedded. Is it possible to configure luaLaTeX to not subset the embedded fonts?

Any other advice on ensuring compatibility with online print on demand services is greatly appreciated.

• That is a ridiculous requirement which will make it impossible to legally use many commercial fonts with the service. I realise that doesn't help since you didn't design the service but if it really requires that, it is still nuts. (It will also make the files people need to upload enormous - imagine a document which uses several opentype fonts each of which includes characters for a range of scripts, alternates, styles etc.) – cfr May 19 '14 at 22:27
• @cfr, I agree. However, as you note, it does not solve my problem. At this point in time, I have an order of booklets with missing symbols so my immediate priority is to gain enough knowledge to at least not bump into the same problem again. I just don't know which handles to tweek to increase the likelihood of success when sending a (LaTeX generated) pdf through a professional printing service. – Martin Heller May 20 '14 at 8:43
• If you have (access to) Acrobat professional, then you could try to (a) preflight your PDF with it (b) re-save your PDF. If your document passes preflight, then I guess you have at least some case against the printing service. If their ripping software can't handle valid PDF, then their service is flawed. With option (b) you probably get a PDF which is more digestible to their RIP, especially if you "downgrade" the version a bit. – Stephan Lehmke Jul 1 '14 at 9:19
• If it's only two characters you are using from this font, you could also make a high-resolution screenshot of those characters and include them via \includegraphics. Of course it is not the most elegant solution but should work and is easier then to rasterize the whole document. – quinmars Jul 1 '14 at 13:24
• @StephanLehmke Lulu re-distilled the document for me and replaced the booklets (200 pcs). However, I would like to avoid this in the future which is difficult as Lulu can't provide a list of requirements for submitted pdfs but only guaranties successful printing if I use a different toolchain. – Martin Heller Jul 1 '14 at 19:55

I do not know of such an option within any tex editor. But if you need a quick fix, try saving the document as a .png using GIMP (www.gimp.org). It will rule out any font problems but introduces large file size problems as mentioned by cfr. Providing them with an image for every page rules out any problems other than mismatched rgb/cymk and such.

When facing such a problem some time ago (in my case, the main font was not recognized at all by the printer), I decided to convert all fonts to curves. Of course, this blows up file-size (can be more than ten times the original size), and the resulting pdf is no longer a good choice for on-screen reading, but printing on paper is absolutely safe. Although I am sure there are also open-source solutions for automatically performing such a text-->curves conversion, I used Adobe Acrobat for that. (See e.g. https://forums.adobe.com/thread/319641)

I suppose that you load the marvosym and awesome packe not before fontspec. This works without a problem with lualatex (up-to-date TL2014):

\documentclass{article}
\usepackage{fontawesome}
\usepackage{marvosym}
\usepackage{fontspec}
\usepackage{libertine}
\usepackage[english]{babel}

\begin{document}
\sffamily
foo \Telefon\ from MArvoSym,
\faInfoSign\ and \faExclamationSign\ commands from the awesome package

\end{document}


name                     type              encoding         emb sub uni object ID
------------------------ ----------------- ---------------- --- --- --- ---------
ALMMHG+LinBiolinumO      CID Type 0C       Identity-H       yes yes yes      4  0
EDYICZ+MarVoSym          Type 1            Builtin          yes yes no       5  0
ZRZEPL+FontAwesome       CID Type 0C       Identity-H       yes yes yes      6  0
EUQFZF+LinLibertineO     CID Type 0C       Identity-H       yes yes yes      7  0


For whatever it's worth, this is still a problem with TeXLive 2018. I included symbols from the current version of FontAwesome, according to pdffonts, the font is properly embedded, but Lulu still won't print those characters for some reason.