8 ms·

This is good news because it renders PDFs a lot faster and better than pdf.js that Firefox uses. Also, I would have to install this binary blob to get Chromium

by reedlaw 12y ago

This is good news because it renders PDFs a lot faster and better than pdf.js that Firefox uses. Also, I would have to install this binary blob to get Chromium to render PDFs. It seems Chromium could easily adopt this, but I'm not sure about Firefox.

shmerl 12y ago
Kpartsplugin with Okular also render PDFs faster in Firefox than pdf.js. I'd expect that all native plugins should be faster (if they are well written).
azakai 12y ago
Well, it wouldn't make sense for Firefox to adopt this: 1. It is tied to v8 (PDFs can run JS, this PDF viewer uses v8 do so - see CJS_Context::RunScript etc), so it would mean bundling 2 JS engines, with all the security downsides of that. 2. This is written in C++. You can sandbox C++ in various ways, but that would still increase the surface area of the browser, compared to pdf.js which only uses things normal web content would use. 3. pdf.js is not just meant to render pdfs, it's also a useful project to push forward the web platform. Areas where pdf.js was slow turned out to be things that were worth optimizing anyhow. This doesn't benefit people viewing pdfs directly, of course, but it's still an interesting aspect of the project.
- comex 12y ago
  Well, Chrome could make this viewer not increase the surface area of the browser just by changing it to a NaCl plugin. After all, it already exposes the ability to run native code inside NaCl to the web. ;p I like the concept of pdf.js, but it's still significantly slower, and thus provides a worse experience to the user, than native viewers.
  - zobzu 12y ago
    i dont know, on recent computers, more often than not i dont really see a diff between pdf.js and others as a user. it seems to only be an issue on really heavy pdfs, which are pretty rare
    - Jyaif 12y ago
      Think mobile.
      - Ygg2 12y ago
        On mobile (Android) both Fx and Chrome start downloading pdfs.
      - JohnTHaller 12y ago
        On mobile, both Firefox and Chrome download PDFs to be rendered by another app on Android. I'm unsure about Chrome on iOS. There is no Firefox for iOS because Apple.
    - keeperofdakeys 12y ago
      I've found pdf.js to be a negative user experience on most pdfs I try to view. From what I've read, this is mainly because pdf.js directly renders to a canvas, and doesn't store decoded vector information. Other readers seem to be able to zoom instantly, even for vector graphics. Firefox also seems to register two separate mime-types for pdf, only giving an option to use pdf.js on one of them. I've yet to dig into firefox and fix this.
    - orbifold 12y ago
      The speed of pdf.js on older computers is abysmal compared to native applications like okular.
  - Hengjie 12y ago
    A large part of why PDF.js is slow is because it doesn't have text coalescing. http://www.NotablePDF.com/ http://www.NotablePDF.com/ is based on PDF.js and has a coalescing code in production which has improved performance substantially. It's been a significant effort on our part, and we'll be contributing it back to the PDFjs code base. Opera also has a similar coalescing effort underway by Christian Krebs.
    - garblegarble 12y ago
      Would you mind explaining what text coalescing is in this context?
      - ehsanu1 12y ago
        Hengjie explains here: https://news.ycombinator.com/item?id=7783622 https://news.ycombinator.com/item?id=7783622
  - pcwalton 12y ago
    > Well, Chrome could make this viewer not increase the surface area of the browser just by changing it to a NaCl plugin. After all, it already exposes the ability to run native code inside NaCl to the web. ;p Will V8 run inside NaCl? As I understand it, the NaCl JIT functionality is pretty slow for use cases like polymorphic inline caching. > I like the concept of pdf.js, but it's still significantly slower, and thus provides a worse experience to the user, than native viewers. Most of the issues in pdf.js are actually rendering-related, not JavaScript-related—that is, they wouldn't be fixed just by changing the language to native code.
    - bla2 12y ago
      > Will V8 run inside NaCl? As I understand it, the NaCl JIT functionality is pretty slow for use cases like polymorphic inline caching. Would that matter for PDFs? I thought js in PDFs is mostly used for form validation, which isn't very compute-heavy.
  - gsnedders 12y ago
    > Well, Chrome could make this viewer not increase the surface area of the browser just by changing it to a NaCl plugin. After all, it already exposes the ability to run native code inside NaCl to the web. ;p AIUI from the NaCl guys, it already does.
- ksec 12y ago
  Then I would rather I have the choose of using PDF with this and Javascript disabled. May be Opera should adopt this.
- yarrel 12y ago
  4. It's not proprietary and doesn't restrict people's ability to freely use their web browser.
  - teraflop 12y ago
    What do you mean by "proprietary"? Pdfium is BSD-licensed, and pdf.js uses the Apache 2 license; both are extremely permissive.
    - async5 12y ago
      Except one does not provide protection from the patents.
- pjmlp 12y ago
  Yeah, but with Chrome reading PDFs is almost like seeing a normal web page, whereas with pdf.js my i7 jumps to 100% CPU usage. In any case, I use a native viewer, which provides the best overall user experience.
  - emn13 12y ago
    That's really weird - I use pdf.js all the time, and suffer no such issues. In particular, I enjoy it's superior font rendering (compared to the chrome implementation). I really don't get why chrome (on windows anyhow) has fairly fuzzy fonts while rendering pdf - noticably worse than pdf.js or acrobat.
    - pjmlp 12y ago
      The rest of the world seems to have similar experience with mine, if you check the threads at this other HN story: https://news.ycombinator.com/item?id=7716022 https://news.ycombinator.com/item?id=7716022
      - icebraining 12y ago
        It happens to me too on Debian, yet PDF.js works fine on my Nexus 7 (2012) table, even though the i7 is much faster than the Tegra 3. It's probably an hardware rendering issue.
      - acdha 12y ago
        A few other people on HN is not “the rest of the world”, particularly when most of the complaints either don't reproduce at all or are significantly less problematic than claimed. It's dead certain that PDF.js has plenty of room to improve but that requires solid benchmarking, not anecdata. I would hope Mozilla is collecting telemetry data about common bottlenecks from millions of users and triaging to see which problems are core or artifacts from local system configuration, graphics drivers, etc.
      - emn13 12y ago
        If you actually read that thread, you'd notice that many people confirm that lots of pdf's render just fine, and that it's specific workloads where pdf.js lags. Frankly, it's something I'll gladly put up with in most cases just to avoid bad font rendering - and that's exactly what I do. BTW, I'm pretty sure that this kind of stuff if pretty platform (and GFX-driver) dependent - and e.g. FF on mac os performs less well IIRC.
- v413 12y ago
  How about converting this viewer through Emscripten using asm.js. Would be interesting to see performance comparison with pdf.js :)
  - espadrine 12y ago
    Especially on Firefox. The product would be asm.js… On the other hand, there might be an initial compilation pause when starting to load the PDF.
    - pcwalton 12y ago
      Caching of the compiled asm.js code is implemented: https://blog.mozilla.org/luke/2014/01/14/asm-js-aot-compilation-and-startup-performance/ https://blog.mozilla.org/luke/2014/01/14/asm-js-aot-compilat...
  - fulafel 12y ago
    Yes. And you could leave out support for PDF-embedded JS for this purpouse.
- deleted 12y ago
  [deleted]
- teacup50 12y ago
  Your arguments aren't supported by the facts: 1. It's not tied to V8. It uses V8 currently, but: - The vast majority of the code has nothing to do with JS. - Almost all of the JS-related PDF code is independent of V8. - The use of V8 is abstracted out sufficiently via IFXJS_Runtime etc that with a bit more work, a different JS runtime could be easily integrated. 2. You note that C/C++ can be sandboxed, but then claim that it "still increases the surface area of the browser". This is nonsense: Firefox's 11 million lines of code are also written in C/C++, and should be sandboxed. You don't increase the surface area by also sandboxing the PDF plugin -- either the sandboxing mechanism works or it doesn't. 3. If anything, pdf.js's continued poor performance and operation demonstrates why forcing everyone to operate inside of a JS runtime is incredibly harmful to the web platform's progress.
  - pcwalton 12y ago
    > You don't increase the surface area by also sandboxing the PDF plugin -- either the sandboxing mechanism works or it doesn't. Adding more C++ to the browser certainly does increase the attack area. Sandboxes that expose enough functionality to run a modern browser engine commonly end up with holes here and there (e.g. the Pwnium vulnerabilities) and it's best to not use them as the only layer of defense; moreover, the sandbox does not fully enforce all of the security properties that the Web platform demands (e.g. cross-origin iframes). > 3. If anything, pdf.js's continued poor performance and operation demonstrates why forcing everyone to operate inside of a JS runtime is incredibly harmful to the web platform's progress. As I mentioned before, pdf.js is not as JS bound as you might think. Furthermore, it was written before asm.js existed and doesn't use any asm.js; if pdf.js were JS bound, then asm.js would be a very powerful option to improve performance that would not involve dropping to unsafe native code.
    - jfbastien 12y ago
      The DRM sandbox is yet another attack surface, isn't it? Wouldn't it make sense to use NaCl for DRM sandboxing, and then the option is open to use the same sandbox for PDF viewing, and pdf.js can still work, giving users choice. Creating yet another sandbox seems silly, and NaCl hasn't been hit by pwnium, it's only been a stepping stone to the renderer (I'll let comex dive into details here!)
e12e 12y ago
I don't really mind pdfjs being slow (it's not really slow enough that I've noticed) -- but it has some serious issues with printing/fonts (not sure quite which) -- even for "simple" pdfs from latex source (your typical paper or math homework) I've had to print from Adobe Acrobat (and, I think evince is also better -- but it's been a long while since I've printed from Linux -- for entirely unrelated reasons).
- stuaxo 12y ago
  I think they are pretty open to adding bad pdfs to their test suite if you have any.
  - orbifold 12y ago
    Pretty much any math and physics paper I tried was rendered with broken fonts and incorrect layout. It is horribly slow and renders a lot of pdfs incorrectly.
- Hengjie 12y ago
  Latex documents are typically slow on PDFjs because it positions characters individually. I think it's because Latex has some specific formatting that the PDF spec/apps can't handle well enough. So for text selection PDFjs wraps each character with it's own absolutely positioned element. The massive number of DOM elements cause browsers to slow down to 5-6fps. I've been working on coalescing the elements and you can see the fruits of my labour by dropping a PDF into https://web.notablepdf.com https://web.notablepdf.com which is an annotation app based on PDF.js.
  - Steuard 12y ago
    Thank you for that explanation! LaTeX docs constitute the vast majority of PDFs that I view, and I've wondered for ages why PDF.js seemed to be so laggy so much of the time.
  - omaranto 12y ago
    Oh, that explains why I thought PDF.js is horrible across the board! If you judged the source of PDF's solely by the ones I read, you'd think every PDF in the world is either produced by LaTeX or is a restaurant menu. Are there statistics about what other sorts of PDF's people read? How else are PDF's made? I always assumed that people that use word processors would exchange files in their word processor's format, but maybe some people export to PDF? (I'm not familiar with the habits of word processor users.)
TwoBit 12y ago
99% of the PDFs I read work fine with the pdf.js reader, and I feel a bit more safe using it than a binary reader.
- oblio 12y ago
  Agreed. pdf.js has come quite a long way from its beta. In most situations I don't feel the need for a native reader, anymore.

by reedlaw 12y ago

shmerl 12y ago

Kpartsplugin with Okular also render PDFs faster in Firefox than pdf.js. I'd expect that all native plugins should be faster (if they are well written).

azakai 12y ago

Well, it wouldn't make sense for Firefox to adopt this: 1. It is tied to v8 (PDFs can run JS, this PDF viewer uses v8 do so - see CJS_Context::RunScript etc), so it would mean bundling 2 JS engines, with all the security downsides of that. 2. This is written in C++. You can sandbox C++ in various ways, but that would still increase the surface area of the browser, compared to pdf.js which only uses things normal web content would use. 3. pdf.js is not just meant to render pdfs, it's also a useful project to push forward the web platform. Areas where pdf.js was slow turned out to be things that were worth optimizing anyhow. This doesn't benefit people viewing pdfs directly, of course, but it's still an interesting aspect of the project.

comex 12y ago
Well, Chrome could make this viewer not increase the surface area of the browser just by changing it to a NaCl plugin. After all, it already exposes the ability to run native code inside NaCl to the web. ;p I like the concept of pdf.js, but it's still significantly slower, and thus provides a worse experience to the user, than native viewers.
- zobzu 12y ago
  i dont know, on recent computers, more often than not i dont really see a diff between pdf.js and others as a user. it seems to only be an issue on really heavy pdfs, which are pretty rare
  - Jyaif 12y ago
    Think mobile.
    - Ygg2 12y ago
      On mobile (Android) both Fx and Chrome start downloading pdfs.
    - JohnTHaller 12y ago
      On mobile, both Firefox and Chrome download PDFs to be rendered by another app on Android. I'm unsure about Chrome on iOS. There is no Firefox for iOS because Apple.
  - keeperofdakeys 12y ago
    I've found pdf.js to be a negative user experience on most pdfs I try to view. From what I've read, this is mainly because pdf.js directly renders to a canvas, and doesn't store decoded vector information. Other readers seem to be able to zoom instantly, even for vector graphics. Firefox also seems to register two separate mime-types for pdf, only giving an option to use pdf.js on one of them. I've yet to dig into firefox and fix this.
  - orbifold 12y ago
    The speed of pdf.js on older computers is abysmal compared to native applications like okular.
- Hengjie 12y ago
  A large part of why PDF.js is slow is because it doesn't have text coalescing. http://www.NotablePDF.com/ http://www.NotablePDF.com/ is based on PDF.js and has a coalescing code in production which has improved performance substantially. It's been a significant effort on our part, and we'll be contributing it back to the PDFjs code base. Opera also has a similar coalescing effort underway by Christian Krebs.
  - garblegarble 12y ago
    Would you mind explaining what text coalescing is in this context?
    - ehsanu1 12y ago
      Hengjie explains here: https://news.ycombinator.com/item?id=7783622 https://news.ycombinator.com/item?id=7783622
- pcwalton 12y ago
  > Well, Chrome could make this viewer not increase the surface area of the browser just by changing it to a NaCl plugin. After all, it already exposes the ability to run native code inside NaCl to the web. ;p Will V8 run inside NaCl? As I understand it, the NaCl JIT functionality is pretty slow for use cases like polymorphic inline caching. > I like the concept of pdf.js, but it's still significantly slower, and thus provides a worse experience to the user, than native viewers. Most of the issues in pdf.js are actually rendering-related, not JavaScript-related—that is, they wouldn't be fixed just by changing the language to native code.
  - bla2 12y ago
    > Will V8 run inside NaCl? As I understand it, the NaCl JIT functionality is pretty slow for use cases like polymorphic inline caching. Would that matter for PDFs? I thought js in PDFs is mostly used for form validation, which isn't very compute-heavy.
- gsnedders 12y ago
  > Well, Chrome could make this viewer not increase the surface area of the browser just by changing it to a NaCl plugin. After all, it already exposes the ability to run native code inside NaCl to the web. ;p AIUI from the NaCl guys, it already does.
ksec 12y ago
Then I would rather I have the choose of using PDF with this and Javascript disabled. May be Opera should adopt this.
yarrel 12y ago
4. It's not proprietary and doesn't restrict people's ability to freely use their web browser.
- teraflop 12y ago
  What do you mean by "proprietary"? Pdfium is BSD-licensed, and pdf.js uses the Apache 2 license; both are extremely permissive.
  - async5 12y ago
    Except one does not provide protection from the patents.
pjmlp 12y ago
Yeah, but with Chrome reading PDFs is almost like seeing a normal web page, whereas with pdf.js my i7 jumps to 100% CPU usage. In any case, I use a native viewer, which provides the best overall user experience.
- emn13 12y ago
  That's really weird - I use pdf.js all the time, and suffer no such issues. In particular, I enjoy it's superior font rendering (compared to the chrome implementation). I really don't get why chrome (on windows anyhow) has fairly fuzzy fonts while rendering pdf - noticably worse than pdf.js or acrobat.
  - pjmlp 12y ago
    The rest of the world seems to have similar experience with mine, if you check the threads at this other HN story: https://news.ycombinator.com/item?id=7716022 https://news.ycombinator.com/item?id=7716022
    - icebraining 12y ago
      It happens to me too on Debian, yet PDF.js works fine on my Nexus 7 (2012) table, even though the i7 is much faster than the Tegra 3. It's probably an hardware rendering issue.
    - acdha 12y ago
      A few other people on HN is not “the rest of the world”, particularly when most of the complaints either don't reproduce at all or are significantly less problematic than claimed. It's dead certain that PDF.js has plenty of room to improve but that requires solid benchmarking, not anecdata. I would hope Mozilla is collecting telemetry data about common bottlenecks from millions of users and triaging to see which problems are core or artifacts from local system configuration, graphics drivers, etc.
    - emn13 12y ago
      If you actually read that thread, you'd notice that many people confirm that lots of pdf's render just fine, and that it's specific workloads where pdf.js lags. Frankly, it's something I'll gladly put up with in most cases just to avoid bad font rendering - and that's exactly what I do. BTW, I'm pretty sure that this kind of stuff if pretty platform (and GFX-driver) dependent - and e.g. FF on mac os performs less well IIRC.
v413 12y ago
How about converting this viewer through Emscripten using asm.js. Would be interesting to see performance comparison with pdf.js :)
- espadrine 12y ago
  Especially on Firefox. The product would be asm.js… On the other hand, there might be an initial compilation pause when starting to load the PDF.
  - pcwalton 12y ago
    Caching of the compiled asm.js code is implemented: https://blog.mozilla.org/luke/2014/01/14/asm-js-aot-compilation-and-startup-performance/ https://blog.mozilla.org/luke/2014/01/14/asm-js-aot-compilat...
- fulafel 12y ago
  Yes. And you could leave out support for PDF-embedded JS for this purpouse.
deleted 12y ago
[deleted]
teacup50 12y ago
Your arguments aren't supported by the facts: 1. It's not tied to V8. It uses V8 currently, but: - The vast majority of the code has nothing to do with JS. - Almost all of the JS-related PDF code is independent of V8. - The use of V8 is abstracted out sufficiently via IFXJS_Runtime etc that with a bit more work, a different JS runtime could be easily integrated. 2. You note that C/C++ can be sandboxed, but then claim that it "still increases the surface area of the browser". This is nonsense: Firefox's 11 million lines of code are also written in C/C++, and should be sandboxed. You don't increase the surface area by also sandboxing the PDF plugin -- either the sandboxing mechanism works or it doesn't. 3. If anything, pdf.js's continued poor performance and operation demonstrates why forcing everyone to operate inside of a JS runtime is incredibly harmful to the web platform's progress.
- pcwalton 12y ago
  > You don't increase the surface area by also sandboxing the PDF plugin -- either the sandboxing mechanism works or it doesn't. Adding more C++ to the browser certainly does increase the attack area. Sandboxes that expose enough functionality to run a modern browser engine commonly end up with holes here and there (e.g. the Pwnium vulnerabilities) and it's best to not use them as the only layer of defense; moreover, the sandbox does not fully enforce all of the security properties that the Web platform demands (e.g. cross-origin iframes). > 3. If anything, pdf.js's continued poor performance and operation demonstrates why forcing everyone to operate inside of a JS runtime is incredibly harmful to the web platform's progress. As I mentioned before, pdf.js is not as JS bound as you might think. Furthermore, it was written before asm.js existed and doesn't use any asm.js; if pdf.js were JS bound, then asm.js would be a very powerful option to improve performance that would not involve dropping to unsafe native code.
  - jfbastien 12y ago
    The DRM sandbox is yet another attack surface, isn't it? Wouldn't it make sense to use NaCl for DRM sandboxing, and then the option is open to use the same sandbox for PDF viewing, and pdf.js can still work, giving users choice. Creating yet another sandbox seems silly, and NaCl hasn't been hit by pwnium, it's only been a stepping stone to the renderer (I'll let comex dive into details here!)

e12e 12y ago

I don't really mind pdfjs being slow (it's not really slow enough that I've noticed) -- but it has some serious issues with printing/fonts (not sure quite which) -- even for "simple" pdfs from latex source (your typical paper or math homework) I've had to print from Adobe Acrobat (and, I think evince is also better -- but it's been a long while since I've printed from Linux -- for entirely unrelated reasons).

stuaxo 12y ago
I think they are pretty open to adding bad pdfs to their test suite if you have any.
- orbifold 12y ago
  Pretty much any math and physics paper I tried was rendered with broken fonts and incorrect layout. It is horribly slow and renders a lot of pdfs incorrectly.
Hengjie 12y ago
Latex documents are typically slow on PDFjs because it positions characters individually. I think it's because Latex has some specific formatting that the PDF spec/apps can't handle well enough. So for text selection PDFjs wraps each character with it's own absolutely positioned element. The massive number of DOM elements cause browsers to slow down to 5-6fps. I've been working on coalescing the elements and you can see the fruits of my labour by dropping a PDF into https://web.notablepdf.com https://web.notablepdf.com which is an annotation app based on PDF.js.
- Steuard 12y ago
  Thank you for that explanation! LaTeX docs constitute the vast majority of PDFs that I view, and I've wondered for ages why PDF.js seemed to be so laggy so much of the time.
- omaranto 12y ago
  Oh, that explains why I thought PDF.js is horrible across the board! If you judged the source of PDF's solely by the ones I read, you'd think every PDF in the world is either produced by LaTeX or is a restaurant menu. Are there statistics about what other sorts of PDF's people read? How else are PDF's made? I always assumed that people that use word processors would exchange files in their word processor's format, but maybe some people export to PDF? (I'm not familiar with the habits of word processor users.)

TwoBit 12y ago

99% of the PDFs I read work fine with the pdf.js reader, and I feel a bit more safe using it than a binary reader.

oblio 12y ago
Agreed. pdf.js has come quite a long way from its beta. In most situations I don't feel the need for a native reader, anymore.