4 ms·

Are there any Linux PDF readers that work as well? For instance I reported this bug https://bugzilla.gnome.org/show_bug.cgi?id=628920 https://bugzilla.gnome.org

Are there any Linux PDF readers that work as well? For instance I reported this bug https://bugzilla.gnome.org/show_bug.cgi?id=628920 https://bugzilla.gnome.org/show_bug.cgi?id=628920 years ago but the example PDF I included still looks horrible in the latest Evince. So I typically keep a copy of Adobe Reader installed to deal with files like that, but I'd love to replace it with something open source.

jpgvm 12y ago
I generally find most PDFs come from the web.. so PDF.js has been more than sufficient for my needs.
aw3c2 12y ago
xpdf renders it nicely, it is anti-userfriendly and ancient though. ;) http://i.imgur.com/9FHRqio.png 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.
- bsznjyewgd 12y ago
  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.
  - aw3c2 12y ago
    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.
bsznjyewgd 12y ago
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.
deleted 12y ago
[deleted]
hello_asdf 12y ago
I've been using zathura and it works quite well.
pbhjpbhj 12y ago
It looks like it's a font [naming/substitution] problem. This http://ubuntuforums.org/showthread.php?t=1363557 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.
naner 12y ago
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.
- skymt 12y ago
  MuPDF claims to support forms and JavaScript as of version 1.2.
- abrowne 12y ago
  PDF.js is not limited to Firefox. Here's a Chrome extension: https://chrome.google.com/webstore/detail/pdf-viewer/oemmndcbldboiebfnladdacbdfmadadm https://chrome.google.com/webstore/detail/pdf-viewer/oemmndc...
Nux 12y ago
This is how it looks in Evince @ CentOS7 http://i.imgur.com/SIq9v4r.png http://i.imgur.com/SIq9v4r.png (including font substitution issue)
soyiuz 12y ago
I am a fan of [Zathura](http://pwmt.org/projects/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.

jpgvm 12y ago

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

aw3c2 12y ago

xpdf renders it nicely, it is anti-userfriendly and ancient though. ;) http://i.imgur.com/9FHRqio.png 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.

bsznjyewgd 12y ago
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.
- aw3c2 12y ago
  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.

bsznjyewgd 12y ago

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.

deleted 12y ago

[deleted]

hello_asdf 12y ago

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

pbhjpbhj 12y ago

It looks like it's a font [naming/substitution] problem. This http://ubuntuforums.org/showthread.php?t=1363557 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.

naner 12y ago

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.

skymt 12y ago
MuPDF claims to support forms and JavaScript as of version 1.2.
abrowne 12y ago
PDF.js is not limited to Firefox. Here's a Chrome extension: https://chrome.google.com/webstore/detail/pdf-viewer/oemmndcbldboiebfnladdacbdfmadadm https://chrome.google.com/webstore/detail/pdf-viewer/oemmndc...

Nux 12y ago

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

soyiuz 12y ago

I am a fan of [Zathura](http://pwmt.org/projects/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.