14 ms·

How fast is PDF.js?

235 points by rnyman 12y ago

angersock 12y ago
Minor performance tip: you can disable the creation of DOM elements backing text and whatnot in PDF.js; this allows for faster rendering on some browsers. You lose easy search, but it can make your life a lot easier if you don't need them.
- windsurfer 12y ago
  You also lose text select (and thus copy+paste)
  - enlashok 12y ago
    But you can approximately restore that if you use Project Naptha as well... urgh... please nobody do this.
- sp332 12y ago
  Is it easy to do that?
  - angersock 12y ago
    Memory suggests yes (I think it's just a render param you pass in or something?) but I'll need to check old code tonight to give you a definitive answer.
  - async5 12y ago
    Yes, you can build you own personalized extension for Firefox, Chrome or Opera from PDF.js source code, which will disable text layer. (see also #textLayer=off feature at https://github.com/mozilla/pdf.js/wiki/Debugging-pdf.js#url-parameters https://github.com/mozilla/pdf.js/wiki/Debugging-pdf.js#url-...)
- bthorben 12y ago
  We realize that the text layer is sometimes a performance problem. We pushed already a lot of improvements to it and there is more too come.
  - angersock 12y ago
    Not your all's fault...the nature of the beast is that a PDF, in the pathological case, could result in thousands and thousands of individually-styled DOM elements per page, right? Not much to be done in that case.
xenophonf 12y ago
"Also security is virtually no issue: using PDF.js is as secure as opening any other website." I can't even begin to express how much this sentiment troubles me. Edited to add: A big part of my concern regarding PDFs these days has to do with embedded malware, but in general I'm wary of active content. I'm all for faster rendering, but I wonder how well PDF.js protects against malicious content. I don't use the native PDF reader for that very reason.
- lebek 12y ago
  Why? The point he's making is that not having to install a third-party browser plugin to view a PDF is a big win for security. Edit in reply to your edit: embedded malware is tailored to exploit a bug in a specific viewer implementation... so I doubt there's much floating around that targets PDF.js, I imagine Adobe Reader is a juicer target. In any case, JS running in the browser is usually well isolated (e.g. no filesystem access), can wreak havoc in the tab but not much else.
  - billiam 12y ago
    The wins on confining the content to the browser sandbox as well as integrating .pdf viewing into the browser experience greatly outweigh the current limitations for large file sizes. I hope ongoing work will fix the latter. Pdf.js is an awesome improvement that makes me breathe easier every time I click on a pdf link.
- daeken 12y ago
  > I'm all for faster rendering, but I wonder how well PDF.js protects against malicious content. It doesn't need to; that's what the browser is for. PDF.js doesn't need to -- in any way -- concern itself with security; that's pretty unquestionably a good thing.
- singlow 12y ago
  By not having a plugin, all of the rendering done by PDF.js is contained within the sandbox normally provided for any page. If a PDF is designed to exploit PDF.js, the worst it can do is the equivalent of a cross-site scripting attack on the page hosting PDF.js. This is a huge win over the possibility of exploiting a bug in a plugin which runs outside of the browser sandbox.
sdfjkl 12y ago
Fast enough, most of the time.
- _delirium 12y ago
  I find it fast enough for reading, but not fast enough for skimming or navigation. If I want to page through a book quickly to find something, it just lags way too much rendering the pages; I have to stop every 5 or 10 pages and wait for it to fill them in, or I'll be paging through nothing but whitespace. But it's fine except for that.
  - bthorben 12y ago
    Keep in mind that PDF.js is an engine + a viewer. Just a fast engine does not make a nice experience. There are many things in the viewer that one can do to make the experience of using it feel a lot faster.
pjmlp 12y ago
So slow and CPU hog even on i7 systems, that I always configure my Firefox installations to save PDFs instead.
- X4 12y ago
  Honestly? I only have 2x1.3GHz, but it loads damn fast for files <= 5MB. How large are the files that you open that make your browser inresponsive?
  - pjmlp 12y ago
    Most of the ones that have more than 10 pages, specially CS papers.
    - aroch 12y ago
      There might be something up with your install--- run away plugin? I read lots of journal articles in FF, many in the 15-30page range with figures, with no problem on an old dual-core iMac.
      - pjmlp 12y ago
        My install?! As I mentioned, in all computer systems I have access to. I just get the spinning wheel effect, while the CPU usage scales all the way up, until the whole document is downloaded, processed and finally displayed.
    - X4 12y ago
      Can you link us to one, so we can do independent tests with it, please?
      - pjmlp 12y ago
        For example the Modula-3 reference manual, 100 pages, when scrolling with the mouse, pages can take more than 1s to render on a i7 system. With native readers, it is almost instantaneous. http://www.hpl.hp.com/techreports/Compaq-DEC/SRC-RR-52.pdf http://www.hpl.hp.com/techreports/Compaq-DEC/SRC-RR-52.pdf
vanderZwan 12y ago
> You see a histogram of the time it took to process all the pages in the PDFs in relation to the average time it takes to process the average page of the Tracemonkey Paper (the default PDF you see when opening PDF.js While interesting data for sure, that's not really answering the same question as the headline there. How about a comparison to the rendering speed of MuPDF?
- kevingadd 12y ago
  MuPDF doesn't solve the same problem, so it doesn't really matter whether MuPDF is faster.
  - renata 12y ago
    MuPDF solves a bit of the same problem, in that it renders PDF while trying to ignore all the extensibility cruft that makes Adobe's PDF reader incredibly insecure.
    - async5 12y ago
      right... http://web.nvd.nist.gov/view/vuln/search-results?query=mupdf&search_type=all&cves=on http://web.nvd.nist.gov/view/vuln/search-results?query=mupdf...
  - vanderZwan 12y ago
    > Maybe you know that there is no default PDF viewer in the Opera Browser, something we would like to change. But how to include one? Buy it from Adobe or Foxit? If that is the problem being addressed, then I think it does? One can ask if patching MuPDF vulnerabilities is a bigger hassle than getting PDF.js performant.
    - bthorben 12y ago
      MuPDF is a very nice piece of software, but it's GPL licensed. As I understand it, this basically prevents MuPDF from actually being used in commercial software ... unless of course we would make the software open source ...
X4 12y ago
PDF.js is really nice and awesome, but for me it doesn't work for documents with a file size of 11MB. It was a catalogue and to finally get the thing to render faster I used pdf2htmlEX (html5) which slimmed the 11MB file down to about 2MB with no visible quality loss and text would still be perfectly selectable, even in old and crappy browsers like IE7. I'm happily using both on a customers site. The 11MB file rendered good enough on my Client's new PC, but they have an i7 ;) My own box is really slow :/ (saving for a macbook pro) Currently I was about to write a service to autoconvert PDF documents uploaded via ownCloud into the said HTML5 document, but it seems that even though I've ssh, this server is managed and doesn't come with make and also has no poppler or fontforge libraries available. Meh :( I'm thinking about compiling the binary with --prefix=~/.local/lib and copy the dependencies I've found to that directory on the server. Hope that works, otherwise I'll need to write an API for pdf2htmlEX on a server where I've root and upload modified & new pdf files to it, then wait for it to finish the html5 conversion and download the files to the right directory using curl. That'd be much more work than just dropping the binary onto the server and executing the service as cronjob for modfied or new files. Any ideas on howto solve this cleverly?
- FooBarWidget 12y ago
  You should probably report this. Most of the test cases that they used where PDF.js is too slow, involves files so large that even Adobe Reader can't render quickly, or files that are heavily damaged.
  - X4 12y ago
    I've reported it and uploaded the pdf, so someone on IRC responsible could debug it, but we didn't get far enough to fix it. Otherwise I wouldn't just add another PDF Viewer to a site. But it's only the downloads section and the preview there really is not for reading, but looking if it's the right document. Anyway, thanks for caring for the project. There's a reason Mozilla chose PDF.js over writing it in C++ and that's not just because of security I think.
- async5 12y ago
  Here is telemetry data from beta users about size of PDFs http://telemetry.mozilla.org/#beta/29/PDF_VIEWER_DOCUMENT_SIZE_KB http://telemetry.mozilla.org/#beta/29/PDF_VIEWER_DOCUMENT_SI... -- typical PDF size is about 200KB, and 11MB is less 20% of them.
Donzo 12y ago
FPDF FTW!
chime 12y ago
I love PDF.js. I built a site recently that uses embedded PDF.js to display PDFs while making it very difficult to print/copy-paste/download these documents. It is super fast, works across all modern browsers, and supports useful PDF features like bookmarks, annotations, and table of contents. It's also pretty easy to customize and theme.
- andreasvc 12y ago
  Please don't do that, you're making the web a worse place. If you're going to sell documents, do what the academic paywalls do: display the first two pages (without any restrictions). Restrictions are just silly because if the content is on the user's computer, you know there is a way for them to get at it.
  - chime 12y ago
    I know where you're coming from and I had this exact same feeling before I embarked on this project. I've been making things for free and giving away my code/projects/services for almost two decades now so I didn't jump into this without serious consideration. I didn't want to write these details in my original post because I was just lauding the PDF.js project. There were more than a few legal requirements for making such a system. We had to show reasonable attempts were made to prevent old copies of the data from existing anywhere i.e. old printouts, copy-pasted notes etc. The documents shown had to be timestamped and watermarked with the user's full name. Unlike the typical public scribd-style document sharing site, this was already behind a login system and 100% of all user activity was monitored with the user's full knowledge. In fact, users demand that their activity to be monitored for legal and auditing purposes. Without going into specifics, imagine a highly skilled professional needs to e-sign that they read a training document V1.23 on date X/Y/Z. This isn't a standard Terms & Conditions agreement that everyone clicks without reading. This is something that affects the professional's abilities to make life or death decisions so they really want to read the correct version of the document. In order to meet all the legal requirements (think stuff like 21 CFR Part 11), the best technical solution turned out to be a browser-based PDF reader that disabled printing/copy-pasting/downloading. I was tasked with building that and thanks to PDF.js, I did so with almost no effort.
fdej 12y ago
It's fine for short documents, but not very pleasant for long math papers. PDF.js takes ~1 second to render a single page in my thesis. In Document Viewer (evince), the delay to render a page is barely perceptible (so I would guess < 0.1 seconds), and Adobe Reader renders pages instantaneously.
- baby 12y ago
  I don't know if I'm the only one to have this problem but it also shows = signs as - signs. (it doesn't always happen and I can't find a pdf where it does that now)
  - async5 12y ago
    Is it https://bugzilla.mozilla.org/show_bug.cgi?id=760997 https://bugzilla.mozilla.org/show_bug.cgi?id=760997 ?
- Gracana 12y ago
  I wish it only took a second to render some of the things I've opened. I've found a lot of the manuals from Automation Direct are very slow to open and navigate. For most things I ignore pdf.js and save files to desktop so I can open them with a "proper" viewer.
deleted 12y ago
[deleted]
Aardwolf 12y ago
Not very fast... when loading a big PDF, before the save button can be used, it needs to render the whole thing first. I don't understand why, because all it has to do is save the file which it already has.
- p01 12y ago
  I believe this is a shortcoming of the default viewer that comes with PDF.js. 'coz as you say saving the file on disk has nothing to do with PDF.js itself. Bare in mind that PDF.js works in older browsers ( IE8 and 9, and even older versions of Opera, Firefox, ... ) so this might drag down the default viewer a bit. Beside, if you know before hand that you want to save the PDF, surely you can right/Cmd click the link and save the file right away. Anyhow, if we - Opera - decide to use PDF.js as the default PDF renderer for the Desktop browser, we will roll our own viewer which can use fancy pancy features like: <a href=# download>Save</a>
anon1385 12y ago
There are several posts on this page touting the security benefits of PDF.js, and it's almost certainly true that PDF.js is more secure than a new pdf implementation in C or C++ would have been[1]. In the short term PDF.js makes sense. I think there are longer term considerations here though. Web standards (HTML/CSS) and language (Javascript) were not designed to be used as a compilation target for complex programs. It was meant to be a document platform. PDF.js is fast enough to use (just about) because a massive amount of engineering time has been put into making browsers very performant. That has involved making browsers huge complex beasts that have to be written in low level unsafe languages to achieve acceptable performance[2]. By choosing to use standards that are very complicated, high level and inefficient we have made the implicit choice to require any competitive browser implementation to be highly optimised and low level. That huge pile of very complex low level code has a real security cost. Buffer overflows, dangling pointers, out of bounds reads. These things are common in browsers today[3] and will remain so while browsers have to be implemented in C++ to remain competitive performance wise. We often engage in debates about whether Javascript/the web stack is fast enough to use for various types of software. Performance improvements are treated as an inevitability; "if it isn't fast enough today it will be tomorrow". Similar attitudes hold for missing APIs and functionality. Most people don't seem to really question what it really means for browsers to become more and more performant and more and more complex. The answer seems to be millions of lines of very complicated and low level C++. I'm aware that Rust is one attempt to extricate ourselves from this hole, but that is years away from ever making it into a production browser, if it ever does. Meanwhile standards continue to increase in complexity and browsers continue implement those additions with large amounts of potentially unsafe C++. I don't have any solutions to this, it's too late, we are already committed to browsers being full operating systems. But while we are all running around patting each other on the back over how 'advanced' browsers are now I do think it's worth considering the security price we are paying to make things like PDF.js possible. [1] I think there is a bit of a false dichotomy here though. If performance is acceptable with Javascript then it presumably would have been acceptable with native languages safer than C/C++ (Java, Haskell, Go, Python, etc, take your pick). [2] For example Chrome seems to have basically a virtual memory system implemented in the browser, with pages, heaps and pagination logic so they can use relative 32 bit pointers. ( http://article.gmane.org/gmane.os.openbsd.misc/186107 http://article.gmane.org/gmane.os.openbsd.misc/186107 ) [3] I don't intend to pick on Firefox specifically here since these types of issues exist in all browsers, but here are some recent Firefox issues form the last month or so: CVE-2014-1518 Various memory safety bugs leading to possible code execution. CVE-2014-1523 Out of bounds read leading to crashes when viewing jpeg images. CVE-2014-1524 Buffer overflow when using non-XBL object as XBL leading to possible code execution. CVE-2014-1531 Use after free when resizing images resulting in a potentially exploitable crash.
pm215 12y ago
"OK on 96% of PDFs" is all very well, but that means that almost 1 document in 20 is performing poorly. It only takes a few slow-rendering documents to make me switch to something else, so if I look at (say) 3 PDF files a day then you've probably lost me as a user within a fortnight.
- kemayo 12y ago
  That does assume that the 1 in 20 which perform poorly are randomly distributed across the set of PDFs. It seems at least plausible that these would actually be grouped up by type somehow (e.g. it mentioned that the worst one they found was a huge vector map of the Lisbon subway system), and thus it would probably be the case that a user would either encounter them far less than that 1 in 20 or far more, depending on their own usage patterns.
- reitanqild 12y ago
  Still faster than the download - wait for Acrobat/Foxit Reader - wait for marginally faster loading document cycle anyway isn't it?
acqq 12y ago
Please do a google search to building plan filetype:pdf (edit: I actually don't know the search terms that would return the real architectural plans and not some texts, I guess somehow Google ranks PDFs with a lot of texts much higher than the documents with drawings -- but I want to point to these actually! If it's true that Google prefers "a lot of text" documents then attempting to googe to get the examples is a good method to miss most of the documents with the real problems!) Then try to actually look at every page of such documents with pdf.js. The first I get is http://www.nist.gov/el/nzertf/upload/NZERTF-Architectural-Plans1-June2011.pdf http://www.nist.gov/el/nzertf/upload/NZERTF-Architectural-Pl... Try it. You will want to throw your fast computer thorough the window. Then when you manage to calm down you'll try to configure your browser to never invoke pdf.js again, if you know that you need to work with such documents. If you want a realistic benchmark, compare the speed of rendering these documents with Adobe's or some other native renderer. I'm not a building architect but I at least don't live in "we don't draw anything significant in our documents" bubble. I know they worry for their potential customers. Forced pdf.js is a huge setback for them. If they would be able to tell the browser in the html "please don't use pdf.js for this one" they would be much happier.
- bthorben 12y ago
  I just tried the mentioned document in the viewer on http://mozilla.github.io/pdf.js/web/viewer.html http://mozilla.github.io/pdf.js/web/viewer.html I agree that the speed is a lot worse than in Preview.app for example, but it's also not unusable. I will look at it in more detail tomorrow
  - acqq 12y ago
    Try to move through the pages, don't stay on the first one! I have the 22nm i7 CPU here and compared to the work with Adobe PDF reader it's just horrible having to use pdf.js. I must however admit that I'm not able to easily construct a Google search for more such documents, but I know a lot of people who work only with such -- they just can't work with pdf.js. Does your benchmark measure the time to actually display everything on every page (what the human looking at all the pages must do), or just the time until the browser is responsible? Edit: inspired from other comments, it seems that at least search for "math plots filetype:pdf" returns more guaranteed problems like http://www.engageny.org/sites/default/files/resource/attachments/math-g5-m4-lessons-1-12.pdf http://www.engageny.org/sites/default/files/resource/attachm... Still it's hard to find slow PDFs with certainty just by using Google.
andyl 12y ago
Does anyone know of a good tool for PDF generation in JavaScript? In Ruby, I use Prawn, which is great. Is there a Prawn-like library for JavaScript?
- gmac 12y ago
  https://github.com/devongovett/pdfkit https://github.com/devongovett/pdfkit (I've also been working on something lower-level — basically support for creating a PDF file out of its raw sections — but it's not quite yet released).
yeukhon 12y ago
The performance is fine but when I have to open PDF files with foreign language neither Adobe or PDF.js can do that well. Adobe will require me to have the font package downloaded. I don't think there is such package for PDF.js which forces me to download the PDF.
- abhishivsaxena 12y ago
  They render fine if fonts are embedded; granted there are many pdfs which don't. But then it's the producers which are to blame.
malandrew 12y ago
Is PDF.js used by Chrome? The reason I ask is because the safe script plugin blocks rendering of all pdfs not from a trusted domain. I find this behavior quite frustrating, since PDFs afaik don't contain (or typically contain tracking code or keep executing code after the initial render of the document).
- azakai 12y ago
  No, Chrome ships a proprietary PDF viewer as native code (Foxit).
tectonic 12y ago
I've had a really good experience implementing a BeeLine Reader PDF coloring algorithm with PDF.js. It was surprisingly easy to work with. http://www.beelinereader.com/pdf http://www.beelinereader.com/pdf
nnethercote 12y ago
I made some big improvements to pdf.js's speed and memory usage a few months ago, particularly for black and white scanned images -- for one 226 page document I saw ~8x rendering speed-ups and ~10x memory usage reductions. Details are here: https://blog.mozilla.org/nnethercote/2014/02/07/a-slimmer-and-faster-pdf-js/ https://blog.mozilla.org/nnethercote/2014/02/07/a-slimmer-an.... These are present in Firefox 29 which only just came out, so if you're seeing bad performance and you're still on 28 or earlier, an upgrade might help. If you have particular PDFs that cause pdf.js to run slowly, please file bugs about them at bugzilla.mozilla.org under the "Firefox" product and the "PDF Viewer" component. PDF is a large, complicated format, so there are many corner cases that the pdf.js developers are unlikely to see without help. Every improvement I made came about from profiling PDFs that people had reported as causing problems.
- TwoBit 12y ago
  I have FireFox 29 and those pages rendered fairly fast for me. Maybe a couple seconds per first viewing of a page, worst case.
  - nnethercote 12y ago
    Which pages do you mean by "those pages"?
    - acqq 12y ago
      Whatever he means, there are also a lot of slow PDF's when googling: controller site:automationdirect.com filetype:pdf
- voltagex_ 12y ago
  Reporting bugs in Firefox is intimidating to say the least. Will a bug filed at GitHub like https://github.com/mozilla/pdf.js/issues/4761 https://github.com/mozilla/pdf.js/issues/4761 still reach the right place? bgirard's profiling work in this thread has been amazing, but I don't think I have the knowledge to interpret the profiler results well enough to file bugs on slow PDFs. A way to post "slow" PDFs to be picked up by pdf.js developers would help.
shmerl 12y ago
When used with heavy PDFs which basically contain tons of images (like scanned books) PDF.js is noticeably slower than native plugins (like Kparts plugin with Okular on KDE) used with Firefox. For more lightweight PDFs it's acceptable.
hendry 12y ago
What does it matter? PDF.js broke quality printing to CUPs, so it's a bit of joke if you break that printing use case. https://bugzilla.mozilla.org/show_bug.cgi?id=932289 https://bugzilla.mozilla.org/show_bug.cgi?id=932289
camus2 12y ago
While PDF is a great tech demo in practice,unless one is using it for short documents,it doesnt work very well.That's why google did what it did with doc,render the pdf as an image them put a transparent text over it. It's a better approach if one has good servers. because frankly one cant expect the browser to behave like acrobat reader and be as performant as native applications when trying to render 20MB pdfs (and a lot of books are that big,this is not an rare use case).
coldtea 12y ago
This is probably the worst benchmark I ever read. Talk about fitting the data to your desired predetermined result. I mean, only check just "popular" PDFs? What about all the people that work with PDFs and are sent custom files for their enterprise/office/design agency etc, and not "popular" stuff. Has he checked what the shape of the distribution curve for popular vs "long tail" PDFs are? Second, using the time to load their intro page as a baseline? How's that relevant? Just because he has this arbitrary subjective idea that "up to 3x that time gives a good user experience"? How about comparing to the time Actobat/Preview take? Lastly, just measures loading the pdf? How about going through the pages?
- p01 12y ago
  The code of the benchmark is open source. Go check how it works and by all mean send a pull request. Any improvement there will shift focus where it matters most and help every user of PDF.js ( in Firefox itself and in the various extensions and services built on top of PDF.js ). The benchmark measures 5x the rendering time of every single page of every single PDF. The problem with benchmarking the "not popular" PDFs is that they're not available outside of their enterprise/office/design agency etc... But if you have any you can share publicly, please file an issue on the Github repository of PDF.js Some people mentioned Mozilla' Telemetry. Unfortunately it is too limited for this kind of research as it can only report enum values. Using Telemetry would need some work to get a baseline/reference for each computer and the results would take weeks or months to come back due to the lag between the master version of PDF.js and the one bundled in Firefox. We compared PDF.js against native viewers. The performance was worse but we can fix this. We already started. For the other things e.g.: rendering quality, color conversions, accessibility, text selection, binary footprint, zoom & scroll, ... PDF.js was on par or better.
rglover 12y ago
Semi-related, but has anybody found a decent PDF generator for JS? Something where you can get a decent quality PDF (none of the screenshot via phantom.js stuff) that's text, a few tables, and a decent layout? Closest example would be an invoice for something. P.S. This would need to work with Node/Meteor.

235 points by rnyman 12y ago

Minor performance tip: you can disable the creation of DOM elements backing text and whatnot in PDF.js; this allows for faster rendering on some browsers. You lose easy search, but it can make your life a lot easier if you don't need them.

windsurfer 12y ago
You also lose text select (and thus copy+paste)
- enlashok 12y ago
  But you can approximately restore that if you use Project Naptha as well... urgh... please nobody do this.
sp332 12y ago
Is it easy to do that?
- angersock 12y ago
  Memory suggests yes (I think it's just a render param you pass in or something?) but I'll need to check old code tonight to give you a definitive answer.
- async5 12y ago
  Yes, you can build you own personalized extension for Firefox, Chrome or Opera from PDF.js source code, which will disable text layer. (see also #textLayer=off feature at https://github.com/mozilla/pdf.js/wiki/Debugging-pdf.js#url-parameters https://github.com/mozilla/pdf.js/wiki/Debugging-pdf.js#url-...)
bthorben 12y ago
We realize that the text layer is sometimes a performance problem. We pushed already a lot of improvements to it and there is more too come.
- angersock 12y ago
  Not your all's fault...the nature of the beast is that a PDF, in the pathological case, could result in thousands and thousands of individually-styled DOM elements per page, right? Not much to be done in that case.

xenophonf 12y ago

"Also security is virtually no issue: using PDF.js is as secure as opening any other website." I can't even begin to express how much this sentiment troubles me. Edited to add: A big part of my concern regarding PDFs these days has to do with embedded malware, but in general I'm wary of active content. I'm all for faster rendering, but I wonder how well PDF.js protects against malicious content. I don't use the native PDF reader for that very reason.

lebek 12y ago
Why? The point he's making is that not having to install a third-party browser plugin to view a PDF is a big win for security. Edit in reply to your edit: embedded malware is tailored to exploit a bug in a specific viewer implementation... so I doubt there's much floating around that targets PDF.js, I imagine Adobe Reader is a juicer target. In any case, JS running in the browser is usually well isolated (e.g. no filesystem access), can wreak havoc in the tab but not much else.
- billiam 12y ago
  The wins on confining the content to the browser sandbox as well as integrating .pdf viewing into the browser experience greatly outweigh the current limitations for large file sizes. I hope ongoing work will fix the latter. Pdf.js is an awesome improvement that makes me breathe easier every time I click on a pdf link.
daeken 12y ago
> I'm all for faster rendering, but I wonder how well PDF.js protects against malicious content. It doesn't need to; that's what the browser is for. PDF.js doesn't need to -- in any way -- concern itself with security; that's pretty unquestionably a good thing.
singlow 12y ago
By not having a plugin, all of the rendering done by PDF.js is contained within the sandbox normally provided for any page. If a PDF is designed to exploit PDF.js, the worst it can do is the equivalent of a cross-site scripting attack on the page hosting PDF.js. This is a huge win over the possibility of exploiting a bug in a plugin which runs outside of the browser sandbox.

sdfjkl 12y ago

Fast enough, most of the time.

_delirium 12y ago
I find it fast enough for reading, but not fast enough for skimming or navigation. If I want to page through a book quickly to find something, it just lags way too much rendering the pages; I have to stop every 5 or 10 pages and wait for it to fill them in, or I'll be paging through nothing but whitespace. But it's fine except for that.
- bthorben 12y ago
  Keep in mind that PDF.js is an engine + a viewer. Just a fast engine does not make a nice experience. There are many things in the viewer that one can do to make the experience of using it feel a lot faster.

pjmlp 12y ago

So slow and CPU hog even on i7 systems, that I always configure my Firefox installations to save PDFs instead.

X4 12y ago
Honestly? I only have 2x1.3GHz, but it loads damn fast for files <= 5MB. How large are the files that you open that make your browser inresponsive?
- pjmlp 12y ago
  Most of the ones that have more than 10 pages, specially CS papers.
  - aroch 12y ago
    There might be something up with your install--- run away plugin? I read lots of journal articles in FF, many in the 15-30page range with figures, with no problem on an old dual-core iMac.
    - pjmlp 12y ago
      My install?! As I mentioned, in all computer systems I have access to. I just get the spinning wheel effect, while the CPU usage scales all the way up, until the whole document is downloaded, processed and finally displayed.
  - X4 12y ago
    Can you link us to one, so we can do independent tests with it, please?
    - pjmlp 12y ago
      For example the Modula-3 reference manual, 100 pages, when scrolling with the mouse, pages can take more than 1s to render on a i7 system. With native readers, it is almost instantaneous. http://www.hpl.hp.com/techreports/Compaq-DEC/SRC-RR-52.pdf http://www.hpl.hp.com/techreports/Compaq-DEC/SRC-RR-52.pdf

vanderZwan 12y ago

> You see a histogram of the time it took to process all the pages in the PDFs in relation to the average time it takes to process the average page of the Tracemonkey Paper (the default PDF you see when opening PDF.js While interesting data for sure, that's not really answering the same question as the headline there. How about a comparison to the rendering speed of MuPDF?

kevingadd 12y ago
MuPDF doesn't solve the same problem, so it doesn't really matter whether MuPDF is faster.
- renata 12y ago
  MuPDF solves a bit of the same problem, in that it renders PDF while trying to ignore all the extensibility cruft that makes Adobe's PDF reader incredibly insecure.
  - async5 12y ago
    right... http://web.nvd.nist.gov/view/vuln/search-results?query=mupdf&search_type=all&cves=on http://web.nvd.nist.gov/view/vuln/search-results?query=mupdf...
- vanderZwan 12y ago
  > Maybe you know that there is no default PDF viewer in the Opera Browser, something we would like to change. But how to include one? Buy it from Adobe or Foxit? If that is the problem being addressed, then I think it does? One can ask if patching MuPDF vulnerabilities is a bigger hassle than getting PDF.js performant.
  - bthorben 12y ago
    MuPDF is a very nice piece of software, but it's GPL licensed. As I understand it, this basically prevents MuPDF from actually being used in commercial software ... unless of course we would make the software open source ...

X4 12y ago

PDF.js is really nice and awesome, but for me it doesn't work for documents with a file size of 11MB. It was a catalogue and to finally get the thing to render faster I used pdf2htmlEX (html5) which slimmed the 11MB file down to about 2MB with no visible quality loss and text would still be perfectly selectable, even in old and crappy browsers like IE7. I'm happily using both on a customers site. The 11MB file rendered good enough on my Client's new PC, but they have an i7 ;) My own box is really slow :/ (saving for a macbook pro) Currently I was about to write a service to autoconvert PDF documents uploaded via ownCloud into the said HTML5 document, but it seems that even though I've ssh, this server is managed and doesn't come with make and also has no poppler or fontforge libraries available. Meh :( I'm thinking about compiling the binary with --prefix=~/.local/lib and copy the dependencies I've found to that directory on the server. Hope that works, otherwise I'll need to write an API for pdf2htmlEX on a server where I've root and upload modified & new pdf files to it, then wait for it to finish the html5 conversion and download the files to the right directory using curl. That'd be much more work than just dropping the binary onto the server and executing the service as cronjob for modfied or new files. Any ideas on howto solve this cleverly?

FooBarWidget 12y ago
You should probably report this. Most of the test cases that they used where PDF.js is too slow, involves files so large that even Adobe Reader can't render quickly, or files that are heavily damaged.
- X4 12y ago
  I've reported it and uploaded the pdf, so someone on IRC responsible could debug it, but we didn't get far enough to fix it. Otherwise I wouldn't just add another PDF Viewer to a site. But it's only the downloads section and the preview there really is not for reading, but looking if it's the right document. Anyway, thanks for caring for the project. There's a reason Mozilla chose PDF.js over writing it in C++ and that's not just because of security I think.
async5 12y ago
Here is telemetry data from beta users about size of PDFs http://telemetry.mozilla.org/#beta/29/PDF_VIEWER_DOCUMENT_SIZE_KB http://telemetry.mozilla.org/#beta/29/PDF_VIEWER_DOCUMENT_SI... -- typical PDF size is about 200KB, and 11MB is less 20% of them.

Donzo 12y ago

FPDF FTW!

chime 12y ago

I love PDF.js. I built a site recently that uses embedded PDF.js to display PDFs while making it very difficult to print/copy-paste/download these documents. It is super fast, works across all modern browsers, and supports useful PDF features like bookmarks, annotations, and table of contents. It's also pretty easy to customize and theme.

andreasvc 12y ago
Please don't do that, you're making the web a worse place. If you're going to sell documents, do what the academic paywalls do: display the first two pages (without any restrictions). Restrictions are just silly because if the content is on the user's computer, you know there is a way for them to get at it.
- chime 12y ago
  I know where you're coming from and I had this exact same feeling before I embarked on this project. I've been making things for free and giving away my code/projects/services for almost two decades now so I didn't jump into this without serious consideration. I didn't want to write these details in my original post because I was just lauding the PDF.js project. There were more than a few legal requirements for making such a system. We had to show reasonable attempts were made to prevent old copies of the data from existing anywhere i.e. old printouts, copy-pasted notes etc. The documents shown had to be timestamped and watermarked with the user's full name. Unlike the typical public scribd-style document sharing site, this was already behind a login system and 100% of all user activity was monitored with the user's full knowledge. In fact, users demand that their activity to be monitored for legal and auditing purposes. Without going into specifics, imagine a highly skilled professional needs to e-sign that they read a training document V1.23 on date X/Y/Z. This isn't a standard Terms & Conditions agreement that everyone clicks without reading. This is something that affects the professional's abilities to make life or death decisions so they really want to read the correct version of the document. In order to meet all the legal requirements (think stuff like 21 CFR Part 11), the best technical solution turned out to be a browser-based PDF reader that disabled printing/copy-pasting/downloading. I was tasked with building that and thanks to PDF.js, I did so with almost no effort.

fdej 12y ago

It's fine for short documents, but not very pleasant for long math papers. PDF.js takes ~1 second to render a single page in my thesis. In Document Viewer (evince), the delay to render a page is barely perceptible (so I would guess < 0.1 seconds), and Adobe Reader renders pages instantaneously.

baby 12y ago
I don't know if I'm the only one to have this problem but it also shows = signs as - signs. (it doesn't always happen and I can't find a pdf where it does that now)
- async5 12y ago
  Is it https://bugzilla.mozilla.org/show_bug.cgi?id=760997 https://bugzilla.mozilla.org/show_bug.cgi?id=760997 ?
Gracana 12y ago
I wish it only took a second to render some of the things I've opened. I've found a lot of the manuals from Automation Direct are very slow to open and navigate. For most things I ignore pdf.js and save files to desktop so I can open them with a "proper" viewer.

deleted 12y ago

[deleted]

Aardwolf 12y ago

Not very fast... when loading a big PDF, before the save button can be used, it needs to render the whole thing first. I don't understand why, because all it has to do is save the file which it already has.

p01 12y ago
I believe this is a shortcoming of the default viewer that comes with PDF.js. 'coz as you say saving the file on disk has nothing to do with PDF.js itself. Bare in mind that PDF.js works in older browsers ( IE8 and 9, and even older versions of Opera, Firefox, ... ) so this might drag down the default viewer a bit. Beside, if you know before hand that you want to save the PDF, surely you can right/Cmd click the link and save the file right away. Anyhow, if we - Opera - decide to use PDF.js as the default PDF renderer for the Desktop browser, we will roll our own viewer which can use fancy pancy features like: <a href=# download>Save</a>

anon1385 12y ago

There are several posts on this page touting the security benefits of PDF.js, and it's almost certainly true that PDF.js is more secure than a new pdf implementation in C or C++ would have been[1]. In the short term PDF.js makes sense. I think there are longer term considerations here though. Web standards (HTML/CSS) and language (Javascript) were not designed to be used as a compilation target for complex programs. It was meant to be a document platform. PDF.js is fast enough to use (just about) because a massive amount of engineering time has been put into making browsers very performant. That has involved making browsers huge complex beasts that have to be written in low level unsafe languages to achieve acceptable performance[2]. By choosing to use standards that are very complicated, high level and inefficient we have made the implicit choice to require any competitive browser implementation to be highly optimised and low level. That huge pile of very complex low level code has a real security cost. Buffer overflows, dangling pointers, out of bounds reads. These things are common in browsers today[3] and will remain so while browsers have to be implemented in C++ to remain competitive performance wise. We often engage in debates about whether Javascript/the web stack is fast enough to use for various types of software. Performance improvements are treated as an inevitability; "if it isn't fast enough today it will be tomorrow". Similar attitudes hold for missing APIs and functionality. Most people don't seem to really question what it really means for browsers to become more and more performant and more and more complex. The answer seems to be millions of lines of very complicated and low level C++. I'm aware that Rust is one attempt to extricate ourselves from this hole, but that is years away from ever making it into a production browser, if it ever does. Meanwhile standards continue to increase in complexity and browsers continue implement those additions with large amounts of potentially unsafe C++. I don't have any solutions to this, it's too late, we are already committed to browsers being full operating systems. But while we are all running around patting each other on the back over how 'advanced' browsers are now I do think it's worth considering the security price we are paying to make things like PDF.js possible. [1] I think there is a bit of a false dichotomy here though. If performance is acceptable with Javascript then it presumably would have been acceptable with native languages safer than C/C++ (Java, Haskell, Go, Python, etc, take your pick). [2] For example Chrome seems to have basically a virtual memory system implemented in the browser, with pages, heaps and pagination logic so they can use relative 32 bit pointers. ( http://article.gmane.org/gmane.os.openbsd.misc/186107 http://article.gmane.org/gmane.os.openbsd.misc/186107 ) [3] I don't intend to pick on Firefox specifically here since these types of issues exist in all browsers, but here are some recent Firefox issues form the last month or so: CVE-2014-1518 Various memory safety bugs leading to possible code execution. CVE-2014-1523 Out of bounds read leading to crashes when viewing jpeg images. CVE-2014-1524 Buffer overflow when using non-XBL object as XBL leading to possible code execution. CVE-2014-1531 Use after free when resizing images resulting in a potentially exploitable crash.

pm215 12y ago

"OK on 96% of PDFs" is all very well, but that means that almost 1 document in 20 is performing poorly. It only takes a few slow-rendering documents to make me switch to something else, so if I look at (say) 3 PDF files a day then you've probably lost me as a user within a fortnight.

kemayo 12y ago
That does assume that the 1 in 20 which perform poorly are randomly distributed across the set of PDFs. It seems at least plausible that these would actually be grouped up by type somehow (e.g. it mentioned that the worst one they found was a huge vector map of the Lisbon subway system), and thus it would probably be the case that a user would either encounter them far less than that 1 in 20 or far more, depending on their own usage patterns.
reitanqild 12y ago
Still faster than the download - wait for Acrobat/Foxit Reader - wait for marginally faster loading document cycle anyway isn't it?

acqq 12y ago

Please do a google search to building plan filetype:pdf (edit: I actually don't know the search terms that would return the real architectural plans and not some texts, I guess somehow Google ranks PDFs with a lot of texts much higher than the documents with drawings -- but I want to point to these actually! If it's true that Google prefers "a lot of text" documents then attempting to googe to get the examples is a good method to miss most of the documents with the real problems!) Then try to actually look at every page of such documents with pdf.js. The first I get is http://www.nist.gov/el/nzertf/upload/NZERTF-Architectural-Plans1-June2011.pdf http://www.nist.gov/el/nzertf/upload/NZERTF-Architectural-Pl... Try it. You will want to throw your fast computer thorough the window. Then when you manage to calm down you'll try to configure your browser to never invoke pdf.js again, if you know that you need to work with such documents. If you want a realistic benchmark, compare the speed of rendering these documents with Adobe's or some other native renderer. I'm not a building architect but I at least don't live in "we don't draw anything significant in our documents" bubble. I know they worry for their potential customers. Forced pdf.js is a huge setback for them. If they would be able to tell the browser in the html "please don't use pdf.js for this one" they would be much happier.

bthorben 12y ago
I just tried the mentioned document in the viewer on http://mozilla.github.io/pdf.js/web/viewer.html http://mozilla.github.io/pdf.js/web/viewer.html I agree that the speed is a lot worse than in Preview.app for example, but it's also not unusable. I will look at it in more detail tomorrow
- acqq 12y ago
  Try to move through the pages, don't stay on the first one! I have the 22nm i7 CPU here and compared to the work with Adobe PDF reader it's just horrible having to use pdf.js. I must however admit that I'm not able to easily construct a Google search for more such documents, but I know a lot of people who work only with such -- they just can't work with pdf.js. Does your benchmark measure the time to actually display everything on every page (what the human looking at all the pages must do), or just the time until the browser is responsible? Edit: inspired from other comments, it seems that at least search for "math plots filetype:pdf" returns more guaranteed problems like http://www.engageny.org/sites/default/files/resource/attachments/math-g5-m4-lessons-1-12.pdf http://www.engageny.org/sites/default/files/resource/attachm... Still it's hard to find slow PDFs with certainty just by using Google.

andyl 12y ago

Does anyone know of a good tool for PDF generation in JavaScript? In Ruby, I use Prawn, which is great. Is there a Prawn-like library for JavaScript?

gmac 12y ago
https://github.com/devongovett/pdfkit https://github.com/devongovett/pdfkit (I've also been working on something lower-level — basically support for creating a PDF file out of its raw sections — but it's not quite yet released).

yeukhon 12y ago

The performance is fine but when I have to open PDF files with foreign language neither Adobe or PDF.js can do that well. Adobe will require me to have the font package downloaded. I don't think there is such package for PDF.js which forces me to download the PDF.

abhishivsaxena 12y ago
They render fine if fonts are embedded; granted there are many pdfs which don't. But then it's the producers which are to blame.

malandrew 12y ago

Is PDF.js used by Chrome? The reason I ask is because the safe script plugin blocks rendering of all pdfs not from a trusted domain. I find this behavior quite frustrating, since PDFs afaik don't contain (or typically contain tracking code or keep executing code after the initial render of the document).

azakai 12y ago
No, Chrome ships a proprietary PDF viewer as native code (Foxit).

tectonic 12y ago

I've had a really good experience implementing a BeeLine Reader PDF coloring algorithm with PDF.js. It was surprisingly easy to work with. http://www.beelinereader.com/pdf http://www.beelinereader.com/pdf

nnethercote 12y ago

I made some big improvements to pdf.js's speed and memory usage a few months ago, particularly for black and white scanned images -- for one 226 page document I saw ~8x rendering speed-ups and ~10x memory usage reductions. Details are here: https://blog.mozilla.org/nnethercote/2014/02/07/a-slimmer-and-faster-pdf-js/ https://blog.mozilla.org/nnethercote/2014/02/07/a-slimmer-an.... These are present in Firefox 29 which only just came out, so if you're seeing bad performance and you're still on 28 or earlier, an upgrade might help. If you have particular PDFs that cause pdf.js to run slowly, please file bugs about them at bugzilla.mozilla.org under the "Firefox" product and the "PDF Viewer" component. PDF is a large, complicated format, so there are many corner cases that the pdf.js developers are unlikely to see without help. Every improvement I made came about from profiling PDFs that people had reported as causing problems.

TwoBit 12y ago
I have FireFox 29 and those pages rendered fairly fast for me. Maybe a couple seconds per first viewing of a page, worst case.
- nnethercote 12y ago
  Which pages do you mean by "those pages"?
  - acqq 12y ago
    Whatever he means, there are also a lot of slow PDF's when googling: controller site:automationdirect.com filetype:pdf
voltagex_ 12y ago
Reporting bugs in Firefox is intimidating to say the least. Will a bug filed at GitHub like https://github.com/mozilla/pdf.js/issues/4761 https://github.com/mozilla/pdf.js/issues/4761 still reach the right place? bgirard's profiling work in this thread has been amazing, but I don't think I have the knowledge to interpret the profiler results well enough to file bugs on slow PDFs. A way to post "slow" PDFs to be picked up by pdf.js developers would help.

shmerl 12y ago

When used with heavy PDFs which basically contain tons of images (like scanned books) PDF.js is noticeably slower than native plugins (like Kparts plugin with Okular on KDE) used with Firefox. For more lightweight PDFs it's acceptable.

hendry 12y ago

What does it matter? PDF.js broke quality printing to CUPs, so it's a bit of joke if you break that printing use case. https://bugzilla.mozilla.org/show_bug.cgi?id=932289 https://bugzilla.mozilla.org/show_bug.cgi?id=932289

camus2 12y ago

While PDF is a great tech demo in practice,unless one is using it for short documents,it doesnt work very well.That's why google did what it did with doc,render the pdf as an image them put a transparent text over it. It's a better approach if one has good servers. because frankly one cant expect the browser to behave like acrobat reader and be as performant as native applications when trying to render 20MB pdfs (and a lot of books are that big,this is not an rare use case).

coldtea 12y ago

This is probably the worst benchmark I ever read. Talk about fitting the data to your desired predetermined result. I mean, only check just "popular" PDFs? What about all the people that work with PDFs and are sent custom files for their enterprise/office/design agency etc, and not "popular" stuff. Has he checked what the shape of the distribution curve for popular vs "long tail" PDFs are? Second, using the time to load their intro page as a baseline? How's that relevant? Just because he has this arbitrary subjective idea that "up to 3x that time gives a good user experience"? How about comparing to the time Actobat/Preview take? Lastly, just measures loading the pdf? How about going through the pages?

p01 12y ago
The code of the benchmark is open source. Go check how it works and by all mean send a pull request. Any improvement there will shift focus where it matters most and help every user of PDF.js ( in Firefox itself and in the various extensions and services built on top of PDF.js ). The benchmark measures 5x the rendering time of every single page of every single PDF. The problem with benchmarking the "not popular" PDFs is that they're not available outside of their enterprise/office/design agency etc... But if you have any you can share publicly, please file an issue on the Github repository of PDF.js Some people mentioned Mozilla' Telemetry. Unfortunately it is too limited for this kind of research as it can only report enum values. Using Telemetry would need some work to get a baseline/reference for each computer and the results would take weeks or months to come back due to the lag between the master version of PDF.js and the one bundled in Firefox. We compared PDF.js against native viewers. The performance was worse but we can fix this. We already started. For the other things e.g.: rendering quality, color conversions, accessibility, text selection, binary footprint, zoom & scroll, ... PDF.js was on par or better.

rglover 12y ago

Semi-related, but has anybody found a decent PDF generator for JS? Something where you can get a decent quality PDF (none of the screenshot via phantom.js stuff) that's text, a few tables, and a decent layout? Closest example would be an invoice for something. P.S. This would need to work with Node/Meteor.