Works flawlessly for all my PDF needs.
Regarding your security concern, Firefox's PDF viewer is PDF.js. Parsing PDF files in a JS sandbox and rendering it to an HTML <canvas> in a sandboxed process should be more secure than rendering it using an unsandboxed app that parses/renders using system APIs.
Almost definitely. You can go to https://www.exploit-db.com/ and search for PDF and see many application exploits for PDF viewers, and that includes for linux (and not just commercial applications, Poppler is on there as well, though more than just a few years back).
PDFs have shown that they are a fertile ground for exploit, so running them though a sandboxed VM is a very good way to limit that problem to some degree.
Huh that's cool that it's fixed now. It annoyed me so much that I installed an extension for it: https://addons.mozilla.org/de/firefox/addon/open-in-browser/
Web browsers are supposed to actually be document viewers. HTML is a document format. I am 100% on-board with web browsers also reading PDFs and EPUBs.
I know Mozilla is hurting for manpower right now, but I'd drop dead with excitement if EPUB support came to Firefox.
I switched to it a while back and haven't looked back since. It's open source too.
That ship sailed long ago. For better or worse, web browsers are application platforms now.
The browser probably won't be good enough to replace Ableton (or similar) for a while but it is the primary medium for a lot of digital (interactive) artwork - for projects that use sound it's nice to plug a MIDI device straight into the browser.
https://github.com/shamadee/web-dsp
> WebDSP is a collection of highly performant algorithms, which are designed to be building blocks for web applications that aim to operate on media data.
> The methods are written in C++ and compiled to WASM, and exposed as simple vanilla Javascript functions developers can run on the client side.
..On further reading, they have functions for video and image processing, but not audio as far as I can tell.
---
There's Glissando, "A web-based digital audio workstation using the web platform APIs (Web Audio, Web MIDI) and WebAssembly".
https://github.com/glissando-daw/glissando-app
They mention "VST support", but I cannot imagine how that's possible from the web.
i also like opening pdf's in a separate app, as they're usually not part of the main "stream of thought" of the page from whence it came.
People would even put in “warning: pdf” text when linking to PDFs because of how Adobe Reader slowed people down.
The release notes do note that a benefit of the built-in viewer is that it’s sandboxed. That’s fair enough, I guess — the Chrome team had a bee in their bonnet about plugins going all the way back to the Chrome launch comic[2].
Interestingly the Chrome team were using svn back then — that’s how long it’s been :-)
[1] https://chromereleases.googleblog.com/2010/12/stable-beta-ch...
Rather annoying to have the wrong web browser launching itself to view PDFs when Firefox does perfectly well at displaying them.
I only get them when the search box goes "You typed 'Snipping Tool' so you probably wanted to search for 'Snipping Tool' on Bing. Let me open that in Edge for you."
I did actually use IE as a frequent browser for a while when I had a Surface, on account of touch scroll/zoom being really bad in Firefox and Chrome at the time. But that was the only thing it had going for it.
EDIT: and as someone else points out, Edge's PDF viewer is now Chrome's PDF viewer and it's not as good
But I've definitely felt the support burden of having three different PDF viewers on a given client PC, along with multiple configurations between them. (You can turn on and off the PDF viewers in each browser, and often embed Adobe Reader into the browser, for instance.)
I don't need anything else besides Evince to read PDF but in order to fill forms I always had to use online tools.
I've never been able to fill a form with Evince.
It also seems to have some odd behaviour in its rendering process, though I've never been able to identify exactly what it is. For example, a plain black-and-white document I printed the other day looked extremely fuzzy, like the early inkjets that only had CMY ink and could only produce "black" as a muddy combination of the other colours. The same document looked normal when reprinted using different software.
Maybe they've improved it since last year or so, but I've gotten into the habit of working around pdf.js.
PDF.js is known to be built into Firefox, I cannot think of why it would be, other than for the purpose of functioning as the core pdf viewer. But I am not that imaginative!
https://github.com/mozilla/pdf.js/wiki/Frequently-Asked-Ques...
I mainly use Acrobat Pro, but I find myself opening my PDFs in Firefox more and more. Acrobat is really slooooooow, it takes ages for a cold start, and after it started the whole thing gets locked up for a minute or so. Absolutely infuriating. PDF.js/Firefox instead is just a smooth ride for me...
For the former, ISO C++ drafts are a good test case. For example, here's C++20 final draft - 1841 pages:
https://isocpp.org/files/papers/N4860.pdf
However, when I tried this in Chrome and Firefox, Firefox not only loaded it just fine, but it is also noticeably faster when scrolling.
For the second, USGS publishes their topographic maps as free PDFs. These have several layers, one of which is the vectorized map, and another is satellite bitmaps.
https://store.usgs.gov/filter-products?sort=relevance&scale=...
The ones with a lot of roads and contour lines (i.e. any city that's on hills) take a while to rasterize. Say, Seattle:
https://store.usgs.gov/product/499688
This one is so slow in Chrome, it's practically unusable - if you zoom in and try to pan around, it can take over a second for it to actually move. This despite the fact that it doesn't even render the satellite layer.
In Firefox, you get the satellite layer (and no way to turn it off, so far as I can tell), and yet it feels more responsive. I think it's because the viewport is always adjusted immediately - actual rendering still takes a while to catch up.
In Adobe Reader the rendering keeps up with scrolling, so long as the satellite layer is not enabled. If it is, it gets jerky when rendering any part for the first time. But it seems to be doing better at caching rendered parts of the document - once it's all rendered, it's smooth panning all around. Chrome and Firefox readers both keep re-rendering parts that go out of view and then back, if you scroll far enough.
The best alternative on windows is PDF-XChange, fairly obscure but extremely feature-rich.
Indeed, it was my PDF reader of choice on Windows for some time.
I do not know if that's still the case.
Heck that could even be integrated into the system print dialog so the application doesn’t even matter.
Neat. I loathe every time I have to install Adobe Reader for something. Unfortunately, all browsers PDF support for things like form filling and stuff tends to be pretty lacking.