The problem with that document (for me) is that it does not embed its fonts, and I do not have the fonts it uses (or any compatible ones) on my computer either. So, when I view it, the font gets substituted by the default sans-serif font, which has completely different (and wrong) metrics. Presumably, Adobe Reader comes with more (compatible) fonts and is able to make better substitution.

In the past, when I have other documents which also don't embed their fonts, but for which I have a compatible substitution font on my computer (that Evince doesn't pick up for whatever reason), I just run it through gs and it embeds the substitution font into the result.

I'm not sure this is really a bug in Evince/poppler in this case as much as a malformed document that presumes the viewer has Century Schoolbook font on their computer.

Your primary choices in renderers are the following:

    - XPDF - the OG *nix PDF renderer.

    - Poppler (fork of xpdf). Probably most featureful,
      different features supported among different 
      implementations (e.g. Evince and Okular appear to 
      behave differently and have different feature sets).

    - Mupdf, newer code base, made by Ghostscript team. Only 
      supports rendering PDFs and XPS. No fancy javascript 
      or form support.

    - PDF.js via Mozilla browsers.

    - PDFium via Chrome-based browsers.

PDF.js is not limited to Firefox. Here's a Chrome extension: https://chrome.google.com/webstore/detail/pdf-viewer/oemmndc...

MuPDF claims to support forms and JavaScript as of version 1.2.

It looks like it's a font [naming/substitution] problem.

This http://ubuntuforums.org/showthread.php?t=1363557 fixed the display of that file for me [Kubuntu 14.04]. I installed a close font "New CenturySchlbk-Normal" and then inserted:

     <match target="pattern">
       <test qual="any" name="family"><string>NewCenturySchlbk</string></test>
       <edit name="family" mode="assign" binding="same"><string>NewCenturySchlbk-Normal</string></edit>
     </match>

in to my /home/username/.config/font-manager/local.conf file.

I didn't need to do anything further. Testing before with fc-match gave:

user@localhost$ fc-match "New CenturySchlbk" DejaVuSans.ttf: "DejaVu Sans" "Book"

Testing after gave:

user@localhost$ fc-match "NewCenturySchlbk" NewCenturySchlbk_Normal.ttf: "NewCenturySchlbk-Normal" "Regular"

Everything I tested on Okular, xpdf, The GIMP, LibreOffice, .., all gave the same results (ie this fix worked on them) except for LibreOffice which failed a lot less after the fix. Perhaps the way the creating program embedded the font was incorrect and so none of the readers good use the embedded font to render the text correctly?

pdf.js did well before, better than Okular or xpdf, but better after the fix too.

I am a fan of [Zathura](http://pwmt.org/projects/zathura/) from pwmt.org. Far faster at rendering large pdfs than Reader of Evince. Vim-like shortcuts as a bonus.

This is how it looks in Evince @ CentOS7 http://i.imgur.com/SIq9v4r.png (including font substitution issue)

xpdf renders it nicely, it is anti-userfriendly and ancient though. ;) http://i.imgur.com/9FHRqio.png

The text looks different because "Syntax Warning: Substituting font 'Times-Roman' for 'NewCenturySchlbk-Roman'".

Crazy how that poppler bug is almost 10 years old and not fixed even though it seems like such an integral part of a PDF library.

I know you already realize it, but others might not, but xpdf is still "bugged" in this case. In the bug report, the missing font is substituted with a default sans-serif font (presumably DejaVu Sans or Ubuntu on Ubuntu), while in your image it is replaced by Times Roman. The spacing of the text is completely wrong in both cases, but it's just worse in the sans-serif case.

I didn't realise that, thanks! Sounds like it might be a good idea to collect such cases and build substitution rules for font-config.

I generally find most PDFs come from the web.. so PDF.js has been more than sufficient for my needs.

I've been using zathura and it works quite well.