Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Firefox introduces PDF viewer

blog.mozilla.org

Post reply on HN
Print view View original

181–190 of 200 posts

Re: Firefox introduces PDF viewer

#181

Post by makomk »

jonknee wrote: post #45
hosay123 wrote: post #9

It's worth pointing out this is done in pure Javascript , and works by compiling PDF functions to equivalent Javascript functions which are then visible to Firefox's JIT. Despite being only around a year old, it still manages to render the majority of PDFs thrown at it (it's been my primary paper reader for the past 6 months or so). As for missing features like some complex gradients, I can't say I've missed them, ex…

> While Mozilla are pumping out stellar designs like this, Google are pushing crap like Native Client and their proprietary, binary-only Foxit Reader solution instead, complete with the hundreds of thousands of LOC of insecure C this entails. Rock on, Mozilla! Why are you dumping on Google? Their browser has been able to handle PDFs for years (including forms!).

So long as you use their proprietary, binary-only version of it. The open-source Chromium cannot display PDFs, and as far as I can tell there's no way to make it capable of doing so.

Re: Firefox introduces PDF viewer

#182

Post by makomk »

omaranto wrote: post #86
makomk wrote: post #22

Earlier quoted context omitted.

From what I can gather Chrome's PDF viewer pretty much is Acrobat Reader. (It's also not available to users of the open-source version Chromium - in fact, as far as I can tell there's no decent way to read PDFs in Chromium at all.)

The PDF viewer in Chrome is available to Chromium users (just copying the libpdf.so or libpdf.DLL file into the appropriate directory works); it's just not open source.

Ahhh. I couldn't find any information on how to do this the last time I looked.

Re: Firefox introduces PDF viewer

#183

Post by epsylon »

CamperBob2 wrote: post #50
shmerl wrote: post #29

It's nice to have such an option, but it feels significantly less snappy than Kparts plugin in KDE which wraps Okular into Firefox.

True, as with plain Adobe Reader. I spend a large part of my day reading .PDFs, both in and out of my browser, and Firefox became a much less effective "power tool" when they took the liberty of disabling the Reader plugin. I couldn't care less how long it takes to load a .PDF -- snappy rendering and navigation is everything, and you don't get that from JavaScript. It took a surprising (to me) amount of hacking to re…

Ditto. I'm perfectly happy with plain Reader (well, at least with versions 9 or 10). I've tried a lot of alternative pdf readers and none has replicated both the nice rendering of the vanilla reader as well as the scrolling behaviour (hand tool and middle click scrolling).

Re: Firefox introduces PDF viewer

#184

Post by morphir »

hosay123 wrote: post #9

It's worth pointing out this is done in pure Javascript , and works by compiling PDF functions to equivalent Javascript functions which are then visible to Firefox's JIT. Despite being only around a year old, it still manages to render the majority of PDFs thrown at it (it's been my primary paper reader for the past 6 months or so). As for missing features like some complex gradients, I can't say I've missed them, ex…

it's not ready for prime just yet. Tried it with my AI-slides, and slide 12 does not render at all. http://www.idi.ntnu.no/emner/tdt4171/slides/Lecture6.pdf

Re: Firefox introduces PDF viewer

#185

Post by Millennium »

eumenides1 wrote: post #108

Dumb question: What's to stop Chrome from eventually adopting PDF.js? Personally, I see that as the future. Its open source, its "good enough", and Google doesn't have to license the pdf viewer anymore. Also it's a big coup against Adobe, when everyone with firefox and chrome can pretty much uninstall your Adobe Reader software. I haven't even mentioned shrinking the market on 3rd party PDF viewers.

Nothing stops Chrome, or even IE, from adopting PDF.js. Not even the license (Apache). Personally, I'd like to see it happen.

Re: Firefox introduces PDF viewer

#186

Post by pifflesnort »

hosay123 wrote: post #9

It's worth pointing out this is done in pure Javascript , and works by compiling PDF functions to equivalent Javascript functions which are then visible to Firefox's JIT. Despite being only around a year old, it still manages to render the majority of PDFs thrown at it (it's been my primary paper reader for the past 6 months or so). As for missing features like some complex gradients, I can't say I've missed them, ex…

You spent the first three paragraphs excusing its failings, and then the last one taking lot shots at Chrome/Google.

Since when has it been more important to meet some developer ideal (JS everywhere) than to provide the best possible product and experience to your customers?

Re: Firefox introduces PDF viewer

#187

Post by pifflesnort »

jlongster wrote: post #69
dhconnelly wrote: post #62

Earlier quoted context omitted.

Gmail, Google Calendar, and Google Docs are huge JavaScript web apps that run in all modern browsers and have enormous user bases. They form a huge part of Google's business. Additionally, Google develops, maintains, and promotes popular JavaScript developer tools like Closure Compiler, AngularJS, and the Chrome dev tools. Are you implying that everyone should just shut down all R&D in web technologies that compete w…

Your last statement is way overstating the original remark about NaCL. Google has definitely been pushing PNaCL as the solution for running large, complex apps that are usually native (like 3d games, and things that require lots of computation) on the web. And there's no way PNaCL is going to be viable in the next decade, it takes way too long for everyone to agree & implement. Gmail, docs, etc are complex, but don't…

One of the major reasons PNaCL is "non-viable" are the comments like this one, calling it non-viable, and insisting on a JS-everywhere future.

If Mozilla et al spent half as much time trying to work with Google as they spend badmouthing everything that isn't JS, we'd have some solutions by now. These are political problems, not technical ones.

Re: Firefox introduces PDF viewer

#189

Post by pifflesnort »

jlongster wrote: post #89
efdee wrote: post #60

Earlier quoted context omitted.

And... ?

It's not just a matter of open/closed source. Bundling in yet another C binary is only going to widen the surface area for security vulnerabilities for millions of people, and there's really not a great reason to do so anymore. PDF.js proves that it's possible to write high-performance javascript to do this stuff, without introducing any security risks and it's completely cross-platform. Computers are only going to g…

JS-everywhere ideologues are always trying to buy a hamburger today and pay for it tomorrow. Someday machines will be faster. Someday the implementation will on par with the alternatives.

How it works today is what matters to users. Tomorrow the native stack will just make use of more hardware features, it will still be faster, and we'll still be having the same conversation that we'be been having with JS ideologues for 10 years now. "Someday ..."

This is what the XML ideologues used to say too. The problem wasn't XML, it was the libraries, or the lack of dedicated XML processing hardware. Then someone realized that if you got rid of the core complexity -- XML -- you could stop layering on piles of additional complexity while trying to work around the root of the problem.

Someday...

Re: Firefox introduces PDF viewer

#190

Post by pifflesnort »

simonster wrote: post #163
drzaiusapelord wrote: post #154

Earlier quoted context omitted.

This is ridiculous. The foxit plugin is fully sandboxed and I have not seen any exploits via any of the netsec lists I subscribe to.

With a couple Google queries, you can find out that the Chrome PDF viewer has had multiple vulnerabilities that allow code to be executed in the sandboxed environment, and that there have also been Chrome vulnerabilities that allow sandboxed code to escape the sandbox. Sandboxing is certainly a good thing, but it's not perfect. Sandboxed code still increases the attack surface. The rationale behind pdf.js is that, be…

The browsers themselves have also been subject to such vulnerabilities. I dare say the attack surface of a full browser implementation is much larger than just the sandboxing, and sandboxing ideally sits behind all I trusted operations in the browser, providing a single common last line of defense.
Post reply on HN