15 ms·

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 Firef

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, except on occasion when dealing with shiny PR materials. Earlier versions occasionally emitted blank pages, but these could always be skipped thanks to a side effect of the PDF format. PDF.js has an amazing future for such a young project, and it is the foremost demonstration of exactly how complex programming tasks can be expressed using native web technologies. Turns out 35kLOC of Javascript almost completely subsumes the functionality of a behemoth native application (Adobe Reader) that on some machines would require half a minute just to 'boot'. 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!

opinali 14y ago
Please take your time machine and go release PDF.js in early 2010. With good performance on the hardware and Javascript VMs of early 2010. Then I'll grant you the criticism of Chrome's PDF viewer. Otherwise, trolling... fact is, Chrome is the browser that liberated the world from Acrobat Reader. PDF.js is awesome and it may be the way to go, but as of today Chrome's viewer is still much better -- please try http://www.irs.gov/pub/irs-pdf/fw4.pdf http://www.irs.gov/pub/irs-pdf/fw4.pdf in both browsers and tell me which one is sluggish and renders so-so, and which renders/scrolls instantly and perfectly and also allows you to actually fill the form.
- Ygg2 14y ago
  They both display about the same (nothing a casual glance could reveal). Firefox took ~ 1 second, while Chrome was slightly faster <1 second. It's hard to count. But it's about the same give or take a few hundred miliseconds. My setup is FF 19.0 and Chrome 24 on Win7 with 8Gb Ram and 3.1GHz processor.
- Scriptor 14y ago
  On average, I might need to fill out a PDF once or twice a year. Otherwise rendering for either one is perfectly fine for me.
  - opinali 14y ago
    This was just a random example. I'm sure if you take a statistically-significant variety of PDFs and benchmark rendering quality, speed and features in all PDF viewers out there, PDF.js won't be any closer to the top; Chrome's viewer will certainly not be the very best but not one of the worst either.
- Watabou 14y ago
  On the mac, Firefox Nightly loads the PDF in a second while Google Chrome Dev loads in about three seconds. I can enter text in the pdf in Chrome while Firefox gives an annoying little "The pdf might not be rendered perfectly" error bar at the top. Let's try Safari: Loads in under a second maybe even faster, super quick scrolling, ability to enter text and the option to download the pdf on the bottom. This is the way browsers should handle pdf. We are just not there yet. I don't want to use Safari though. Firefox is the browser for me. I almost always download the pdf anyways and view it through Preview.app, especially if I want to actually input text in the pdf. I love Preview. It's like the best PDF reader out there. Preview is what liberated me from Acrobat. Well, switching to the Mac did that for me, really.
  - ___1___ 14y ago
    I don't have firefox and a pdf view won't change that. Your description of Safari matches that of Chromium on Arch Linux.
    - Watabou 14y ago
      Does Chromium have a built in PDF reader? I thought google adds that in for Chrome along with Flash?
      - natex 14y ago
        It is not included, but can be installed. (libpdf) https://wiki.archlinux.org/index.php/Chromium#Open_PDF_files_inside_Chromium https://wiki.archlinux.org/index.php/Chromium#Open_PDF_files...
    - omaranto 14y ago
      I don't think that's right: I use Chromium on Arch Linux and it does not seem to have a PDF viewer. It always offers to download PDFs and open them with a separate program, often warning me first that PDFs from unknown sources can be dangerous.
  - jpxxx 14y ago
    To be sure, Safari is invoking a system level PDF reader to handle inline PDFs. That's what gets you that silky performance and nice rendering. When you pop the PDF out, it then gets passed to the full Preview.app.
- makomk 14y ago
  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.)
  - snotrockets 14y ago
    The pdf.js repository contains a Chrome/Chromium plugin, which works for me. YMMV.
  - omaranto 14y ago
    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.
    - chc 14y ago
      I think for most people, when they say "available," they mean "without copyright infringement."
      - keeperofdakeys 14y ago
        As long as you don't distribute chromium with this file, then it will be fine. (You do it yourself).
      - omaranto 14y ago
        I'm not sure what the rules are: Google gives me permission to install Chrome, and then, presumably I have permission to delete everything but the PDF viewer plugin, right? Maybe the Chrome EULA disallows this, but, to be honest, I didn't read it.
    - makomk 14y ago
      Ahhh. I couldn't find any information on how to do this the last time I looked.
  - comex 14y ago
- chc 14y ago
  Was early 2011 that different a place? Anecdotally, I've run PDF.js on a PowerPC desktop from 2005 with a late 2011 version of Firefox, and it was a bit pokier than I'd like, but it was usable for me. (BTW: Apologies, it looks like I somehow fat-fingered a downvote on your post. Unfortunately there's no way to undo that on Hacker News. No slight intended.)
- deleted 14y ago
  [deleted]
- comex 14y ago
  Mac users would say it was Safari. :)
  - wmf 14y ago
    Or OmniWeb before that. PDF in the browser? Congrats, you're only twelve years behind.
- blinkingled 14y ago
  >Chrome's viewer is still much better On Linux - both FF19 and Chrome Stable are very close. FF rendering is a bit jerkier than Chrome but not by much.
- jareds 14y ago
  Since I'm blind Firefox wins every time over Google Chrome. I tried out the link you had in your comment and I can at least read some of the text in Firefox with my screen reading software. I assume this is because Firefox turns it into some form of HTML that is then accessible through the normal function of assistive technology. Google Chrome uses some kind of plugin that doesn’t provide any accessibility support so I get a blank page without any text. Even if the performance isn’t as good I’d much rather deal with things that are rendered to HTML and JavaScript.
  - opinali 14y ago
    This is a good point, but a separate issue (and kudos to PDF.js if accessibility was a purposeful design point of their implementation, not just a happy coincidence... they could certainly have chosen other avenues, such as generating a WebGL scene that would be opaque to screen readers). And Chrome's viewer should indeed be accessible, I'll raise this question internally.
    - bazzargh 14y ago
      For that to have been a happy coincidence is basically impossible with PDF. You're told a run of positioned glyphs to render, but then you have to figure out what text those really represent by looking at the font tables (even the simplest documents tend to contain ligatures)...and that's before you assemble the runs into sentences, paragraphs, columns etc, generally without help from the PDF, although it can optionally contain this info. The first version of PDF.js rendered positioned images of text runs, text extraction came later and was definitely deliberate. (I was paying attention, as I wrote some of the code to do multicolumn text selection in poppler)
- meaty 14y ago
  Bollocks. Chrome's PDF implementation absolutely sucks. I have numerous PDF documents which it can't handle at all. I've just opened them in Firefox 19 and they are absolutely spot on. I'm uninstalling Acrobat reader for a week to see how it goes now. Chrome never gave me that.
  - iso-8859-1 14y ago
    Can you link them please? We already have links to PDF's rendering better in Chrome. I'd like to see where pdf.js does a better job.
    - meaty 14y ago
      Unfortunately not as they contain sensitive information (financial contracts).
- Terretta 14y ago
  > Please take your time machine and go [to] early 2010... Chrome's PDF viewer... fact is, Chrome is the browser that liberated the world from Acrobat Reader. Fact check: August 31, 2006: "Current versions of Safari are able to access PDF documents in a number of different ways. It can display the documents inline (in the Web browser window) without the use of a plug-in, it can use the Adobe Preview plug-in to display documents inline with added controls, or it can pass PDF viewing duties off to another application like Adobe Reader or Apple's own Preview.app." http://reviews.cnet.com/8301-13727_7-10327228-263.html http://reviews.cnet.com/8301-13727_7-10327228-263.html "Google Chrome ... was released as a beta version for Microsoft Windows on September 2, 2008, and as a stable public release on December 11, 2008." http://en.wikipedia.org/wiki/Google_Chrome http://en.wikipedia.org/wiki/Google_Chrome
  - jf22 14y ago
    Safari, outside of mobile, just isn't used like Chrome is. Chrome liberated us from Adobe Reader because its what we actually use.
- emn13 14y ago
  Uhm... on my machine, the firefox version actually loads this just as quickly and with notably smoother scrolling? I guess it's the other way around on your machine. It doesn't allow form filling though. Honestly I couldn't care either way. Even the acrobat plugin seems to be much better behaved these days, so...
- fafner 14y ago
  Chrome's PDF viewer lacks the basic features one expects from a PDF viewer. It doesn't make sense to abandon the concept of pages or not support ToC. Those things are essential in PDFs. pdf.js handles all of those things. And there were browsers being able to display PDF before Chrome. KDE's Konqueror could simply load KPDF and Safari had Preview.app embedded. I wish Google would abandon their viewer (which is closed source btw) and rather start using and contributing to pdf.js.
anatoly 14y ago
Your comment would've been so much better without its last paragraph.
- emn13 14y ago
  It's lovely how one comment like that also manages to turn the whole thread into a them vs. us flamewar :-(
- anoncow 14y ago
  I don't understand the open source hate. Whether the code is open source or not makes a lot of difference. Not hating on google, but mozilla has this one right.
DASD 14y ago
I thought one of the safety features of some pdf readers was the ability to disable javascript. How does that work here if this is entirely implemented in javascript? Disregard if I'm not understanding this correctly.
- rcthompson 14y ago
  I believe the security feature is the ability to disable Javascript code that is included within the pdf file. A pdf reader implemented in Javascript is perfectly capable of doing that.
  - stock_toaster 14y ago
    Not only that, but being able to render via js would (and thus avoid calling out to any plugin code) would be able to take advantage of sandboxing too I imagine.
    - pifflesnort 14y ago
      How do you evaluate the PDF's JavaScript in an interpreter that is distinct from the renderer's?
- meaty 14y ago
  Different layers of abstraction. JavaScript embedded in a PDF probably turns up as a string after being parsed. It doesn't necessarily get eval'ed. It's turtles all the way down, until you say no.
  - DASD 14y ago
    Let's hope there is the option to say no otherwise this couldn't be considered a general purpose viewer by some.
jonknee 14y ago
> 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!).
- snotrockets 14y ago
  Chrome's PDF plugin is closed source, and written in C. It is very useful, but not free as in FOSS.
  - efdee 14y ago
    And... ?
    - lclarkmichalek 14y ago
      Something being closed source matters to some people. You might not be one of them, but other people might have different perspectives that cause them to value an open source option above a closed source equivalent.
      - siddhant 14y ago
        Yes but the masses don't care if it's open or closed source.
        LeonidasXIV 14y ago
        No, but we should. For the masses that don't.
        PavlovsCat 14y ago
        That the masses don't care about open source is reason to work really hard to educate them; not reason to not care either.
dhconnelly 14y ago
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 with or don't use JavaScript?
- jlongster 14y ago
  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 require tons of computation. They just require good web technologies. Google's work in this area is awesome, but that doesn't mean we can't call out PNaCL as a bad technology to push.
  - pifflesnort 14y ago
    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.
    - khuey 14y ago
      http://news.ycombinator.com/item?id=4632410 http://news.ycombinator.com/item?id=4632410
      - pifflesnort 14y ago
        Yes, I think that demonstrates my point, given that the author is Brendan Eich, CTO of Mozilla. Mozilla has had years to contribute something meaningful to the conversation, and instead they've consistently badmouthed Google's efforts while watching the meteoric rise of native mobile development. So now they've finally brought asm.js to the table; a Mozilla-flavored common bytecode, which is what we've been wanting for years, and exactly what Eich and Mozilla said was wrong for the web: http://en.wikipedia.org/wiki/Google_Native_Client#Reception http://en.wikipedia.org/wiki/Google_Native_Client#Reception Fine -- if using javascript to encode a bytecode is what it takes for Mozilla to actually take the need for a common bytecode seriously (and admit that DOM/JS/HTML/CSS is perhaps not adequate), then I won't look a gift horse in the mouth. I just wish they'd figured out the need for post-JS webapps a little sooner.
chr1 14y ago
It's really pretty good (and i've been using it for a while on firefox nightly), but unfortunately it uses lot's of memory, scolling past 4-5 pages on math heavy papers usually kills my old 1gb ram pc.
cynwoody 14y ago
> 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. Given how well PDF.js runs using Mozilla's JS engine, I have to wonder how well it would perform with V8.
- mccr8 14y ago
  You can try it out for yourself here by loading this URL with Chrome: http://mozilla.github.com/pdf.js/web/viewer.html http://mozilla.github.com/pdf.js/web/viewer.html
  - cynwoody 14y ago
    That's outstanding, even if the graphical figures still need work.
wslh 14y ago
Yes but native client is conceptually an excellent and secure way to run native code.
jfb 14y ago
To be fair, Reader does a lot more than simply display PDFs. Not of course that that makes PDF.js any less impressive.
Tloewald 14y ago
If this based on pdf.js, because after being initially thrilled by it, we found it to be unusably buggy on all major browsers.
EvanYou 14y ago
While pdf.js is a cool project, the last paragraph sounds too biased. Despite being open source / in native javascript, Firefox is still late to the party in terms of viewing pdf in a browser. Coming up with a better solution TWO YEARS later than the competitor doesn't seem that impressive.
hakaaaaak 14y ago
"Google are pushing crap" Is Google plural?
morphir 14y ago
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 http://www.idi.ntnu.no/emner/tdt4171/slides/Lecture6.pdf
pifflesnort 14y ago
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?

opinali 14y ago

Please take your time machine and go release PDF.js in early 2010. With good performance on the hardware and Javascript VMs of early 2010. Then I'll grant you the criticism of Chrome's PDF viewer. Otherwise, trolling... fact is, Chrome is the browser that liberated the world from Acrobat Reader. PDF.js is awesome and it may be the way to go, but as of today Chrome's viewer is still much better -- please try http://www.irs.gov/pub/irs-pdf/fw4.pdf http://www.irs.gov/pub/irs-pdf/fw4.pdf in both browsers and tell me which one is sluggish and renders so-so, and which renders/scrolls instantly and perfectly and also allows you to actually fill the form.

Ygg2 14y ago
They both display about the same (nothing a casual glance could reveal). Firefox took ~ 1 second, while Chrome was slightly faster <1 second. It's hard to count. But it's about the same give or take a few hundred miliseconds. My setup is FF 19.0 and Chrome 24 on Win7 with 8Gb Ram and 3.1GHz processor.
Scriptor 14y ago
On average, I might need to fill out a PDF once or twice a year. Otherwise rendering for either one is perfectly fine for me.
- opinali 14y ago
  This was just a random example. I'm sure if you take a statistically-significant variety of PDFs and benchmark rendering quality, speed and features in all PDF viewers out there, PDF.js won't be any closer to the top; Chrome's viewer will certainly not be the very best but not one of the worst either.
Watabou 14y ago
On the mac, Firefox Nightly loads the PDF in a second while Google Chrome Dev loads in about three seconds. I can enter text in the pdf in Chrome while Firefox gives an annoying little "The pdf might not be rendered perfectly" error bar at the top. Let's try Safari: Loads in under a second maybe even faster, super quick scrolling, ability to enter text and the option to download the pdf on the bottom. This is the way browsers should handle pdf. We are just not there yet. I don't want to use Safari though. Firefox is the browser for me. I almost always download the pdf anyways and view it through Preview.app, especially if I want to actually input text in the pdf. I love Preview. It's like the best PDF reader out there. Preview is what liberated me from Acrobat. Well, switching to the Mac did that for me, really.
- ___1___ 14y ago
  I don't have firefox and a pdf view won't change that. Your description of Safari matches that of Chromium on Arch Linux.
  - Watabou 14y ago
    Does Chromium have a built in PDF reader? I thought google adds that in for Chrome along with Flash?
    - natex 14y ago
      It is not included, but can be installed. (libpdf) https://wiki.archlinux.org/index.php/Chromium#Open_PDF_files_inside_Chromium https://wiki.archlinux.org/index.php/Chromium#Open_PDF_files...
  - omaranto 14y ago
    I don't think that's right: I use Chromium on Arch Linux and it does not seem to have a PDF viewer. It always offers to download PDFs and open them with a separate program, often warning me first that PDFs from unknown sources can be dangerous.
- jpxxx 14y ago
  To be sure, Safari is invoking a system level PDF reader to handle inline PDFs. That's what gets you that silky performance and nice rendering. When you pop the PDF out, it then gets passed to the full Preview.app.
makomk 14y ago
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.)
- snotrockets 14y ago
  The pdf.js repository contains a Chrome/Chromium plugin, which works for me. YMMV.
- omaranto 14y ago
  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.
  - chc 14y ago
    I think for most people, when they say "available," they mean "without copyright infringement."
    - keeperofdakeys 14y ago
      As long as you don't distribute chromium with this file, then it will be fine. (You do it yourself).
    - omaranto 14y ago
      I'm not sure what the rules are: Google gives me permission to install Chrome, and then, presumably I have permission to delete everything but the PDF viewer plugin, right? Maybe the Chrome EULA disallows this, but, to be honest, I didn't read it.
  - makomk 14y ago
    Ahhh. I couldn't find any information on how to do this the last time I looked.
- comex 14y ago
chc 14y ago
Was early 2011 that different a place? Anecdotally, I've run PDF.js on a PowerPC desktop from 2005 with a late 2011 version of Firefox, and it was a bit pokier than I'd like, but it was usable for me. (BTW: Apologies, it looks like I somehow fat-fingered a downvote on your post. Unfortunately there's no way to undo that on Hacker News. No slight intended.)
deleted 14y ago
[deleted]
comex 14y ago
Mac users would say it was Safari. :)
- wmf 14y ago
  Or OmniWeb before that. PDF in the browser? Congrats, you're only twelve years behind.
blinkingled 14y ago
>Chrome's viewer is still much better On Linux - both FF19 and Chrome Stable are very close. FF rendering is a bit jerkier than Chrome but not by much.
jareds 14y ago
Since I'm blind Firefox wins every time over Google Chrome. I tried out the link you had in your comment and I can at least read some of the text in Firefox with my screen reading software. I assume this is because Firefox turns it into some form of HTML that is then accessible through the normal function of assistive technology. Google Chrome uses some kind of plugin that doesn’t provide any accessibility support so I get a blank page without any text. Even if the performance isn’t as good I’d much rather deal with things that are rendered to HTML and JavaScript.
- opinali 14y ago
  This is a good point, but a separate issue (and kudos to PDF.js if accessibility was a purposeful design point of their implementation, not just a happy coincidence... they could certainly have chosen other avenues, such as generating a WebGL scene that would be opaque to screen readers). And Chrome's viewer should indeed be accessible, I'll raise this question internally.
  - bazzargh 14y ago
    For that to have been a happy coincidence is basically impossible with PDF. You're told a run of positioned glyphs to render, but then you have to figure out what text those really represent by looking at the font tables (even the simplest documents tend to contain ligatures)...and that's before you assemble the runs into sentences, paragraphs, columns etc, generally without help from the PDF, although it can optionally contain this info. The first version of PDF.js rendered positioned images of text runs, text extraction came later and was definitely deliberate. (I was paying attention, as I wrote some of the code to do multicolumn text selection in poppler)
meaty 14y ago
Bollocks. Chrome's PDF implementation absolutely sucks. I have numerous PDF documents which it can't handle at all. I've just opened them in Firefox 19 and they are absolutely spot on. I'm uninstalling Acrobat reader for a week to see how it goes now. Chrome never gave me that.
- iso-8859-1 14y ago
  Can you link them please? We already have links to PDF's rendering better in Chrome. I'd like to see where pdf.js does a better job.
  - meaty 14y ago
    Unfortunately not as they contain sensitive information (financial contracts).
Terretta 14y ago
> Please take your time machine and go [to] early 2010... Chrome's PDF viewer... fact is, Chrome is the browser that liberated the world from Acrobat Reader. Fact check: August 31, 2006: "Current versions of Safari are able to access PDF documents in a number of different ways. It can display the documents inline (in the Web browser window) without the use of a plug-in, it can use the Adobe Preview plug-in to display documents inline with added controls, or it can pass PDF viewing duties off to another application like Adobe Reader or Apple's own Preview.app." http://reviews.cnet.com/8301-13727_7-10327228-263.html http://reviews.cnet.com/8301-13727_7-10327228-263.html "Google Chrome ... was released as a beta version for Microsoft Windows on September 2, 2008, and as a stable public release on December 11, 2008." http://en.wikipedia.org/wiki/Google_Chrome http://en.wikipedia.org/wiki/Google_Chrome
- jf22 14y ago
  Safari, outside of mobile, just isn't used like Chrome is. Chrome liberated us from Adobe Reader because its what we actually use.
emn13 14y ago
Uhm... on my machine, the firefox version actually loads this just as quickly and with notably smoother scrolling? I guess it's the other way around on your machine. It doesn't allow form filling though. Honestly I couldn't care either way. Even the acrobat plugin seems to be much better behaved these days, so...
fafner 14y ago
Chrome's PDF viewer lacks the basic features one expects from a PDF viewer. It doesn't make sense to abandon the concept of pages or not support ToC. Those things are essential in PDFs. pdf.js handles all of those things. And there were browsers being able to display PDF before Chrome. KDE's Konqueror could simply load KPDF and Safari had Preview.app embedded. I wish Google would abandon their viewer (which is closed source btw) and rather start using and contributing to pdf.js.

anatoly 14y ago

Your comment would've been so much better without its last paragraph.

emn13 14y ago
It's lovely how one comment like that also manages to turn the whole thread into a them vs. us flamewar :-(
anoncow 14y ago
I don't understand the open source hate. Whether the code is open source or not makes a lot of difference. Not hating on google, but mozilla has this one right.

DASD 14y ago

I thought one of the safety features of some pdf readers was the ability to disable javascript. How does that work here if this is entirely implemented in javascript? Disregard if I'm not understanding this correctly.

rcthompson 14y ago
I believe the security feature is the ability to disable Javascript code that is included within the pdf file. A pdf reader implemented in Javascript is perfectly capable of doing that.
- stock_toaster 14y ago
  Not only that, but being able to render via js would (and thus avoid calling out to any plugin code) would be able to take advantage of sandboxing too I imagine.
  - pifflesnort 14y ago
    How do you evaluate the PDF's JavaScript in an interpreter that is distinct from the renderer's?
meaty 14y ago
Different layers of abstraction. JavaScript embedded in a PDF probably turns up as a string after being parsed. It doesn't necessarily get eval'ed. It's turtles all the way down, until you say no.
- DASD 14y ago
  Let's hope there is the option to say no otherwise this couldn't be considered a general purpose viewer by some.

jonknee 14y ago

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

snotrockets 14y ago
Chrome's PDF plugin is closed source, and written in C. It is very useful, but not free as in FOSS.
- efdee 14y ago
  And... ?
  - lclarkmichalek 14y ago
    Something being closed source matters to some people. You might not be one of them, but other people might have different perspectives that cause them to value an open source option above a closed source equivalent.
    - siddhant 14y ago
      Yes but the masses don't care if it's open or closed source.
      - LeonidasXIV 14y ago
        No, but we should. For the masses that don't.
      - PavlovsCat 14y ago
        That the masses don't care about open source is reason to work really hard to educate them; not reason to not care either.

dhconnelly 14y ago

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 with or don't use JavaScript?

jlongster 14y ago
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 require tons of computation. They just require good web technologies. Google's work in this area is awesome, but that doesn't mean we can't call out PNaCL as a bad technology to push.
- pifflesnort 14y ago
  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.
  - khuey 14y ago
    http://news.ycombinator.com/item?id=4632410 http://news.ycombinator.com/item?id=4632410
    - pifflesnort 14y ago
      Yes, I think that demonstrates my point, given that the author is Brendan Eich, CTO of Mozilla. Mozilla has had years to contribute something meaningful to the conversation, and instead they've consistently badmouthed Google's efforts while watching the meteoric rise of native mobile development. So now they've finally brought asm.js to the table; a Mozilla-flavored common bytecode, which is what we've been wanting for years, and exactly what Eich and Mozilla said was wrong for the web: http://en.wikipedia.org/wiki/Google_Native_Client#Reception http://en.wikipedia.org/wiki/Google_Native_Client#Reception Fine -- if using javascript to encode a bytecode is what it takes for Mozilla to actually take the need for a common bytecode seriously (and admit that DOM/JS/HTML/CSS is perhaps not adequate), then I won't look a gift horse in the mouth. I just wish they'd figured out the need for post-JS webapps a little sooner.

chr1 14y ago

It's really pretty good (and i've been using it for a while on firefox nightly), but unfortunately it uses lot's of memory, scolling past 4-5 pages on math heavy papers usually kills my old 1gb ram pc.

cynwoody 14y ago

> 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. Given how well PDF.js runs using Mozilla's JS engine, I have to wonder how well it would perform with V8.

mccr8 14y ago
You can try it out for yourself here by loading this URL with Chrome: http://mozilla.github.com/pdf.js/web/viewer.html http://mozilla.github.com/pdf.js/web/viewer.html
- cynwoody 14y ago
  That's outstanding, even if the graphical figures still need work.

wslh 14y ago

Yes but native client is conceptually an excellent and secure way to run native code.

jfb 14y ago

To be fair, Reader does a lot more than simply display PDFs. Not of course that that makes PDF.js any less impressive.

Tloewald 14y ago

If this based on pdf.js, because after being initially thrilled by it, we found it to be unusably buggy on all major browsers.

EvanYou 14y ago

While pdf.js is a cool project, the last paragraph sounds too biased. Despite being open source / in native javascript, Firefox is still late to the party in terms of viewing pdf in a browser. Coming up with a better solution TWO YEARS later than the competitor doesn't seem that impressive.

hakaaaaak 14y ago

"Google are pushing crap" Is Google plural?

morphir 14y ago

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 http://www.idi.ntnu.no/emner/tdt4171/slides/Lecture6.pdf

pifflesnort 14y ago

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?