I recently had a small odyssey with PDF and fonts when preparing camera-ready versions of my two most recent papers. It started with the following error message from HotCRP format checker: “Bad font: unnamed Type3 fonts first referenced on page X”.
I cannot even comprehend the error message on first sight – what is a Type 3 font? After some googling, I learned that the definition of “types” comes from PostScript, and a Type 3 font is a font stored as bitmaps instead of vector glyphs that you and I would expect. Such fonts are designed for specific devices (say, a 300-DPI printer) and would naturally be ugly when displayed on monitors, even more so when zoomed in/out. So, HotCRP and most publishers (rightfully) decide to ban such fonts from camera-ready papers.
I’m still slightly confused though. I have always thought that PDFs are basically vector pictures. Why do they need to care about fonts? It turns out that the text is actually not lost when typeset into a PDF file. The text is encoded (with a standard or nonstandard encoding) and stored in the PDF, accompanied by a hint on which font to use to display it. It is the PDF viewer’s job to draw the glyphs of the text using a proper font on the screen. Note that the font itself may or may not be embedded in the PDF file. If so, the embedded font will always be used. If not, the viewer will choose a locally-available font as a substitute. This font-embedding business is another source of trouble by itself. Publishers (again, rightfully) want final papers to look the same on all devices regardless of what fonts are locally available, so they generally require all fonts to be embedded, which may or may not be the default for LaTeX and gnuplot. But let’s get back to Type 3 fonts for now.
So, the error message basically says “I found ugly Type 3 fonts used in the PDF”. The first question is how it got in there. The page number in the error message and some tweaking led me to believe the problem comes from figures generated by gnuplot. Another round of googling led me to a bunch of other users sharing the same problem.
Solving the problem
Usually, the diagnosis from stackoverflow would be: gnuplot on macOS does strange stuff and uses Type 3 fonts for spaces in captions and labels. It does not show this behavior on Linux. Someone did file a ticket for this bug, but unfortunately, the developer pointed out that gnuplot does not handle fonts by itself, and suggested looking at its dependencies. This looks like a rabbit hole to me. The suggested solution is usually re-generating the plots on Linux.
As a side note, if you would like to see for yourself that there are indeed Type 3
fonts in the document, you may install the
pdffonts tool from the
package (available in Homebrew). Then, run
pdffonts your-figure.pdf and you should
see something like this:
name type encoding emb sub uni object ID ------------------------------------ ----------------- ---------------- --- --- --- --------- [none] Type 3 Custom yes no yes 6 0 FDCBUM+Helvetica TrueType WinAnsi yes yes yes 7 0 CQDHZB+Helvetica TrueType WinAnsi yes yes yes 8 0 [none] Type 3 Custom yes no yes 9 0
If you embed this figure into a paper, the PDF output of the paper will contain Type 3 fonts.
As mentioned before, the optimal solution is to re-generate the figures and try to not let Type 3 fonts sneak in. However, sometimes it is difficult or impossible. For example, I do not even know why gnuplot on macOS would use Type 3 fonts. Or, I may have figures which I have lost the original script to generate. Or, I may not want to take the risk that the re-generated plot may look different from the original, peer-reviewed version. It would be great if there is a way to fix the PDF plots I’ve already got.
The solution is actually simple. I just remove all fonts from the figure. Recall that fonts are there to help show text, and there is little text in a figure. So, we can simply draw the plot as a pure vector image, with text rendered into vector shapes. This process is called “outlining”. Some quick googling led me to the one-liner:
gs -o output.pdf -dNoOutputFonts -sDEVICE=pdfwrite input.pdf
If you run
pdffonts on the output, you will notice that all fonts are gone.
HotCRP should stop complaining if you embed the output into the paper.
Note that you should definitely not run this on the full paper. It will convert your paper into a huge vector picture. Although the text will look the same, the PDF viewer will just treat them as vector shapes, and functions like search or highlight will break.
Finally, if you do have time to redraw the plots, you may set the gnuplot
terminal to postscript. The output from this terminal does not contain Type 3
fonts. Note that you should also enable
color for the terminal.