[withjive]

Project Mortar is different in the fact that it is PDFium and Adobe Flash being allowed via Pepper API — basically it's for sandboxing those current native plugins. This would not be a public web use case.

PNaCl vs WebAssembly was all about letting everybody run sandboxed native code in the browser without any extensions or prompts.

Native Client (the portable version known as PNaCl) was an open source project by google to achieve native performance with sandbox security.

Mozilla wanted a more open web which led to Web Assembly.

[indolering]

Yeah, AFAIK PDFium doesn't use PNaCI and Flash will only be around as long as absolutely necessary. The only reason they aren't using PDF.js is because the PDf spec is ~12K pages long and they don't want to throw engineer resources at it anymore.

[phonon]

> they don't want to throw engineer resources at it anymore.

"As I mentioned elsewhere, there haven't been any full time mozilla devs on PDF.js for quite awhile. I'm not sure I actually see the whole maintenance cost savings argument since PDF.js has practically cost Mozllia nothing the last few years. A lot of bug fixes have come from unpaid contributors in that time. Initially, PDFium was pitched as a freebie if we added support for chromium's flash and then we'd also get improved PDF printing and form support. However, the amount of effort that has gone into supporting PDFium is already far beyond what it would have taken to improve PDF.js form support and help improve Firefox's printing (which would have benefited the web in general). Though, this is my very biased opinion as I was tech lead of PDF.js."[1]

And this has been borne out--Project Mortar was announced about 9 months ago, and if you look at the relevant bugs in bugzilla, they are still pretty far away from getting it into production. They could have used a fraction of those resources to get pdf.js at parity with pdfium.

[1] https://news.ycombinator.com/item?id=12615559

[thristian]

I'm sad to see PDF.js go. The PDF spec is ~12K pages long, and most of those pages describe things I don't want my PDF viewer to support, like embedded Flash, in much the same way I don't want my browser to support Flash.

PDF.js is at a very comfortable nexus of compatibility and efficiency, and I kind of wish I could use it for non-web-PDFs as well (but not so much that I want to put it in an Electron wrapper).

[Caspy7]

PDF.js isn't "going" per se, but its lack of inclusion and development may certainly take wind out of its sails. It should still be possible as a PDF viewer in the browser (as an addon). And I think you can already use it (inside Firefox) to view non-web-PDFs.

[indolering]

I totally agree that we shouldn't be throwing random PDFs at that pile of C++ code, but I'm not sure there is much of an alternative.

I'm not personally familiar with those internals, but from my past life in the print industry it took decades for print controllers to reliably handle native PDFs. And it's still not a sure thing[0].

And it's not a stationary spec, it's in Adobe's best interest to keep throwing in new features so they can license new versions of their software. It's literally a rehash of the old school office suite document formats.

Google is willing to cover those development costs because they need it for Android, ChromeOS, and Google Docs. So let them pay for it. This is doubly true if (as I suspect) this becomes the de-facto FOSS PDF implementation.

0: https://arstechnica.com/information-technology/2017/05/micro...