In my experience Evince (the PDF reader in Gnome) works much better than PDF.js (and is faster, has smaller footprint, supports more advanced PDF feature, etc).
I personally quite like MuPDF for its simplicity but mostly I'm simply viewing a document, it doesn't support forms or probably a number of other PDF features.
What's wrong with Okular? I like having PDF.js in my browser for quick previews and I find it way more preferable than what Chrome does with its plugin, but on the desktop I wouldn't really choose PDF.js over Okular.
There are decent tools for PDF. (La)TeX being one, poppler being another, qpdf being yet another that I used and found very useful for manipulating PDFs, like removal of useless watermarks. There are plenty of other tools that can work with PDFs, like inkscape, libreoffice, ImageMagick,...
On Windows I like Sumatra (https://www.sumatrapdfreader.org/free-pdf-reader.html), it's only a few MBs and opens blazing fast and I have never had a problem reading any PDFs with it. There's also some nifty things you can do with its CLI.
This particular solution may not be solving the problem I need, but I'd love to see a really good version of PDF.js running in electron for existing electron apps.
Use case: You're building an electron app. It needs to view pdfs. Right now, you need to implement pdf.js yourself. It's non trivial. And the more full-featured you want it, the harder it is.
And that's only half the issue. What if you want a cross-platform way to create a thumbnail of a pdf? Ugg, don't let me get started on ghostscript...
Did Pdf.js ever get their SVG backend working? Without that printing was basically broken since it just printed out each page as a bitmap from canvas at like 96 dpi which ended up being low res / fuzzy on paper.
People seem skeptical of this because of Electron fatigue, but keep in mind that if your browser's built-in PDF rendering is native code, there's potentially a security win to replacing that attack surface with Pdf.js. Already, we go to some trouble to train people to open attachments on Google Drive's web viewers rather than by double-clicking on them.
Everything that runs on a computer is run as, or by, native code at some point, and that doesn't make it automatically insecure.
At the same time, since Electron uses a browser, any potentially unsafe native code in the browser is loaded and waiting to be exploited anyway when using this viewer.
Finally, I think most people (myself included) trust their browser developer more than they trust a random person's Javascript thrown on GitHub.
That said, I don't see why anybody would use this over mupdf or evince.
Managed runtimes being harder to exploit than native code written in an unsafe language is not a controversial idea that you're going to kill by judicious application of the axiomatic method.
What I want from a PDF viewer is dark mode (white on black). I know on MacOS you can do invert colours, but that inverts the images too.
Also I want to be able to view portrait PDFs in landscape mode with the text in 2 columns.
36 comments
[ 258 ms ] story [ 799 ms ] threadThere aren't decent PDF tools for Linux and this is also based on web standards which is awesome.
The combination of older/robust technology like PDF but with modern web standards is really compelling.
https://en.wikipedia.org/wiki/PDF/A
https://en.wikipedia.org/wiki/History_of_the_Portable_Docume...
Use case: You're building an electron app. It needs to view pdfs. Right now, you need to implement pdf.js yourself. It's non trivial. And the more full-featured you want it, the harder it is.
And that's only half the issue. What if you want a cross-platform way to create a thumbnail of a pdf? Ugg, don't let me get started on ghostscript...
Embed statically linked versions of imagick in your program or download them upon first load/setup.
Except on OSX, where you can use SIPS. But on Windows, you're stuck with IM/GS.
The FAQ says it's been baked into Firefox since v19: https://github.com/mozilla/pdf.js/wiki/Frequently-Asked-Ques...
Everything that runs on a computer is run as, or by, native code at some point, and that doesn't make it automatically insecure.
At the same time, since Electron uses a browser, any potentially unsafe native code in the browser is loaded and waiting to be exploited anyway when using this viewer.
Finally, I think most people (myself included) trust their browser developer more than they trust a random person's Javascript thrown on GitHub.
That said, I don't see why anybody would use this over mupdf or evince.
If I download a PDF it's because I want to open it in my regular PDF viewer (mupdf) and not in a crappy browser based one.