[pdftex] Type 1 font problem

Allin Cottrell cottrell at wfu.edu
Sat Jan 20 19:31:07 CET 2018

I'm having trouble displaying certain PDF files created by pdflatex 
and incorporating proprietary Type 1 fonts. I have access to two 
Linux systems, call them A and B, and the deal is that PDF files 
created from the same sources on either system display correctly on 
system A but not on B. The symptoms of incorrect display are: using 
xpdf, text appears but is seriously wonky (missing glyphs and 
curious blotches), while using evince no text is displayed and I see 
"error occurred in libfreetype" on stderr.

The two systems have these characteristics:

A: Fedora fc26
pdfTeX, Version 3.14159265-2.6-1.40.17 (TeX Live 2016)
(preloaded format=pdflatex 2017.2.7)
LaTeX2e <2016/03/31>

B: Arch (fully updated 2018-01-20)
pdfTeX, Version 3.14159265-2.6-1.40.18 (TeX Live 2017/Arch Linux)
(preloaded format=pdflatex)
LaTeX2e <2017-04-15>

The Type 1 font families I'm trying are Adobe Caslon, Bulmer MT, 
Bembo, Bodoni MT, Baskerville MT and Scotch Roman MT. In each case 
I'm using the same, simple LaTeX document for testing. Of these 
fonts the first two provoke the problem on System B while the other 
four display correctly on both systems.

None of the files provoke any error when examined by pdinfo or qpdf 
(though I know these are not rigorous tests). And to be clear, all 
of the test files (all fonts, PDF produced on both A and B) display 
perfectly correctly on System A in both xpdf and evince. Moreover, 
I've been using all of these fonts in LaTeX for many years without 
any problem and it's just recently I've noticed that they're not 
working on System B.

I tried the experiment of replacing System B's libfreetype with that 
from System A, but that didn't make any difference. Then I tried 
running System A's xpdf binary on System B: again, no change in 

Clearly there's something in the PDF rendering stack on System B 
that is choking on some of the files. I guess this could be because 
(a) some of the PDFs are actually broken according to spec, but the 
rendering stack on A is somehow more fault-tolerant and succeeds in 
working around the brokenness, or (b) the PDFs are OK and there's a 
subtle breakage somewhere in the rendering stack on B (but 
apparently not in libfreetype).

Anyone have an idea on how I should proceed to get a more useful 
diagnosis? Thanks in advance.

Further info: at http://users.wfu.edu/cottrell/t1problem/ I've put 
screenshots of good and bad (xpdf) renditions of my test file, plus 
the source fonttest.tex and sample output fonttest.pdf using Adobe 

Allin Cottrell
Department of Economics
Wake Forest University

More information about the pdftex mailing list