A standards-based PDF viewer created using Electron and Pdf.js | Hacker News Reader

A standards-based PDF viewer created using Electron and Pdf.js

github.com

32 pointsburtonator35 comments

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.

SumatraPDF and muPDF for really big pdfs. When on the mood, I use my trusty GSView.

Sumatra PDF can open .cbr/.cbz files too. So, it serves as a comic reader too.

I really dont understand why I should open a new browser instance (Electron) to view one pdf when I could just open it in my browser..

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...

> 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.

Someone who knows how to do that probably isn’t programming in electron.

ImageMagick requires Ghostscript to handle pdfs. So you need both.

Except on OSX, where you can use SIPS. But on Windows, you're stuck with IM/GS.

What do you mean by "standards-based"?

I'm not sure what the authors mean, but although PDF was created by Adobe there is an ISO standardized version of it now.

https://en.wikipedia.org/wiki/PDF/A

PDF proper is an ISO standard, too:

https://en.wikipedia.org/wiki/History_of_the_Portable_Docume...

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.

Doesn't Firefox itself use pdf.js for PDF rendering?

The FAQ says it's been baked into Firefox since v19: https://github.com/mozilla/pdf.js/wiki/Frequently-Asked-Ques...

Yes, Pdf.js is a Mozilla project, right?

That line of reasoning seems specious.

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.

But if you use PDF viewer in Chrome, it is properly sandboxed from the rest of OS. Is this app sandboxed as well? I don't think so.

We have truly come full circle

It’s too bad electron won’t run in display postscript environments.

And this does display PDFs with embedded HTML pages? Could these embedded web pages contain pdf.js again to show an embedded PDF?

You've just inceptioned yourself to OUT OF MEMORY crash!

Or you could just open PDF with your browser.

Every one of the browser and/or Javascript based PDF viewers I've used has been a terrible experience, and this one doesn't seem to be any different.

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.

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.

Zathura supports this (and is otherwise awesome, too)

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.

A PDF viewer that eats up half my RAM. Just what I needed.

zathura is nice on *nix, has support for multiple pdf rendering engines (muPDF and poppler).

I think this project deserves a lot more attention.

There 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.

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 totally agree.

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,...

There aren't decent PDF tools for linux? I've always found the opposite.

Reply on news.ycombinator.com