
How fast is PDF.js? - rnyman
https://hacks.mozilla.org/2014/05/how-fast-is-pdf-js/
======
acqq
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-
Pl...](http://www.nist.gov/el/nzertf/upload/NZERTF-Architectural-
Plans1-June2011.pdf)

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.

~~~
bgirard
I just profiled your example:
[http://people.mozilla.org/~bgirard/cleopatra/#report=4b995cc...](http://people.mozilla.org/~bgirard/cleopatra/#report=4b995cc512452cbcba17032f0a5d400904a5d09d)

Looks like it could be running much faster:

* 20% of the time is spent copying the canvas because someone is, likely erroneously, holding a reference to the canvas. Looking into it: [https://bugzilla.mozilla.org/show_bug.cgi?id=1007897](https://bugzilla.mozilla.org/show_bug.cgi?id=1007897)

* 10% of the time is spent waiting on display transactions swaps because canvas isn't triple buffered.

* PDF.js is not getting empty transaction (canvas draw optimizations).

That's just from a quick profile. I'm sure there's a ton more things that
could be improved.

~~~
acqq
A little OT, but since you're so good at profiling Firefox, I have one more
interesting "a lot of real work" page that will maybe inspire you or somebody
you know:

[http://bellard.org/jslinux/](http://bellard.org/jslinux/)

This emulates in JavaScript the x86 and necessary hardware to really boot
Linux 2.6.20(!) On my computer, Opera 12.17 will show "booted in 2.8 seconds,"
versus Firefox 29 on which it will be "booted in 7.9 seconds." That's 2.8
times slower.

~~~
bgirard
Here's a profile:
[http://people.mozilla.org/~bgirard/cleopatra/#report=0705c03...](http://people.mozilla.org/~bgirard/cleopatra/#report=0705c034076cf86361b20cedc3254d4552347a41)

I get between 5-7 seconds here.

Looks like getaliasedvar is causing excessive bailouts from Ion (3rd tier
JIT). On top of that the platform is trying to synchronously cancel background
Ion Jitting and that is taking an excessive amount of time. Reported as:
[https://bugzilla.mozilla.org/show_bug.cgi?id=1007927](https://bugzilla.mozilla.org/show_bug.cgi?id=1007927)

Tweaking the functions listed in the profile to avoid them bailing out should
drastically improve this test case.

~~~
acqq
And at the opposite side of Bellard's useful code, I've also observed that a
simple loop which just does the summation of the doubles like this

    
    
        var s = 0.01
        for ( var i = 0; i < 100000000; i++ )
            s += 0.1
        print( s )
    

Became around twice slower since some version of Firefox (of course, before
that point there were a lot of speedups, very old FF can't be compared with
the present state).

Still, really the biggest problems I know of at the moments are those PDFs
that the architects produce.

~~~
kevingadd
That loop doesn't actually do anything, benchmarking it is pretty much
meaningless.

It's important to have benchmarks that aren't trivially converted to no-ops or
constant loads by the compiler. (In practice the JIT might not be optimizing
that one out, but an aggressive C++ compiler certainly would as long as fast
math is enabled - so at some point, a typical JS JIT will too).

Also ensure that you're benchmarking warmed code that has been fully jitted.
JS code (other than asm.js in Firefox) has multiple stages of compilation in
modern runtimes, typically triggered based on how often it is called.

~~~
acqq
You are wrong. The last line has the meaning of displaying the result to the
user (you are supposed to implement it there, I'm lazy. The same goes for
prior warm-up, I don't have to specify it here, I just show the loop). Because
the result is needed to be shown, the browser is certainly not allowed to
optimize away the calculation. Second, it's not allowed to replace it with a
multiplication, as it's a floating point arithmetics and the binary
representation of the constants involved is not "nice" an the same stands for
partial results too. Do compare the result with the multiplication to get the
idea (10000000.01 vs 9999999.99112945). All the additions have to be performed
one way or another between the loading of the js and the displaying of the
result. So it is a good measure of the quality of the translation from the js
to the machine code which does the actual calculation and can also easily
point to the unnecessary overheads as it's very simple. The regression I
observed is therefore a real one, probably observable in other scenarios but
harder to pinpoint and probably avoidable, as the better results did exist
once. (Of course, if it would be part of some widely popular benchmark cheats
would probably be developed, but at the moment there aren't any. Once anybody
implements "we don't care for numerics" optimization, it of course should not
be used anymore to asses the quality of JS).

------
nnethercote
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-
an...](https://blog.mozilla.org/nnethercote/2014/02/07/a-slimmer-and-faster-
pdf-js/). 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.

~~~
keeperofdakeys
Since you've done some work on it, I'll assume you understand the architecture
well. My biggest gripe with pdf.js is that resizing triggers a full page
reload, since it has to redraw the canvas. Whereas this is instant on other
pdf readers. Would there be any workarounds for this? Or will we be stuck with
this behaviour till "pdf.js 2.0".

Edit: This is an example of what I'm talking about
[https://github.com/mozilla/pdf.js/issues/3853](https://github.com/mozilla/pdf.js/issues/3853)

~~~
nnethercote
> Since you've done some work on it, I'll assume you understand the
> architecture well.

Alas, no :) My work was basically a few surgical strikes in which I learned a
lot about a few small corners, but my overall understanding of the code base
is pretty weak.

I recommend filing a new issue here:
[https://github.com/mozilla/pdf.js/issues/new](https://github.com/mozilla/pdf.js/issues/new)

------
fdej
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
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
Is it
[https://bugzilla.mozilla.org/show_bug.cgi?id=760997](https://bugzilla.mozilla.org/show_bug.cgi?id=760997)
?

------
X4
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
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
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.

------
angersock
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.

~~~
sp332
Is it easy to do that?

~~~
async5
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-...](https://github.com/mozilla/pdf.js/wiki/Debugging-pdf.js#url-
parameters))

------
coldtea
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
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.

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

~~~
X4
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
Most of the ones that have more than 10 pages, specially CS papers.

~~~
X4
Can you link us to one, so we can do independent tests with it, please?

~~~
pjmlp
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)

~~~
nknighthb
Unable to reproduce on a 2.6GHz Core i7. It's slower than the viewer in
Chrome, to be sure, but not to the degree you describe.

[https://drive.google.com/file/d/0B0Ne3vac3uJuOTB0Y2owLVN3MzQ](https://drive.google.com/file/d/0B0Ne3vac3uJuOTB0Y2owLVN3MzQ)

------
pm215
"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
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.

------
vanderZwan
> _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
MuPDF doesn't solve the same problem, so it doesn't really matter whether
MuPDF is faster.

~~~
renata
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
right... [http://web.nvd.nist.gov/view/vuln/search-
results?query=mupdf...](http://web.nvd.nist.gov/view/vuln/search-
results?query=mupdf&search_type=all&cves=on)

------
anon1385
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.

~~~
loup-vaillant
> _Web standards (HTML /CSS) and language (Javascript) were not designed to be
> used as a compilation target for complex programs._

[http://asmjs.org/](http://asmjs.org/) —
[https://www.destroyallsoftware.com/talks/the-birth-and-
death...](https://www.destroyallsoftware.com/talks/the-birth-and-death-of-
javascript)

Now they are.

> _I don 't have any solutions to this, it's too late, we are already
> committed to browsers being full operating systems._

When we do get to that point, and ditch the underlying MacWinuX, there's a
good chance they won't be much more complex and much less secure than what
they replaced. A typical MacWinuX desktop setup is already over 200 Millions
lines of code. I'd be happy to drop that to a dozen million lines instead
(even though 20K are probably closer to the mark
[http://vpri.org/html/work/ifnct.htm](http://vpri.org/html/work/ifnct.htm)).
It also shouldn't be much slower than current native applications.

Heck, it may even be significantly _faster_. Without native code, hardware
doesn't have to care about backward compatibility any more! Just patch the
suitable GCC or LLVM back end, and recompile the brO-Ser. New processors will
be able to have better instruction sets, be tuned for JIT compilation… The
Mill CPU architecture for instance, with its low costs for branch
mispredictions, already looks like nice target for interpreters.

\---

> _I do think it 's worth considering the security price we are paying to make
> things like PDF.js possible._

Remember the 200 million lines I mentioned above? We're _already_ paying that
security price. For a long time, actually.

\---

That said, I agree with your main point: the whole thing sucks big time, and
it would be real nice if we could just start over, and have a decent full
featured system that fit in, say 50.000 lines or so. Of course, that means
forgoing backward compatibility, planning for many cores right away… Basically
going back to the 60s, with hindsight.

Alas, as Richard P. Gabriel taught us, it'll never happen.

~~~
peterashford
I don't think you have to forgo backwards compatibility. Implement a standard
VM and library set that everyone can compile to. Implement HTML/JS as a module
in the new system. Problem solved.

~~~
loup-vaillant
Well, it's not just HTML/JS. It's Word/OpenDocument, SMTP/POP/IMAP… Those
modules are going to make for the vast majority of the code. We could easily
go from 50K lines to several millions.

------
tectonic
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)

------
sdfjkl
Fast enough, most of the time.

~~~
_delirium
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
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.

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

------
chime
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
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
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.

~~~
andreasvc
I wasn't primarily thinking of making things free, that is obviously not
always possible. What I argue against is introducing artificial and
superficial restrictions, in the form of restricting GUI actions. This gives a
false sense of security, because the underlying data is still on the user's
computer and technically they can do whatever they want with it. Instead I
believe the system that you talk about should rely on trust, something which
cannot be established by technical means. Yes you could require the user to
scroll through the whole document, even require a minimum of x seconds per
page, or give 20 questions after they read it, but ultimately there is no
substitute for trusting the user and their reading comprehension ... Of course
I understand that you're not in a position to change these requirements.

------
malandrew
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
No, Chrome ships a proprietary PDF viewer as native code (Foxit).

------
rglover
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.

------
yeukhon
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
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.

------
hendry
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)

------
shmerl
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.

------
Aardwolf
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
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>

------
andyl
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
[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).

------
Donzo
FPDF FTW!

------
xenophonf
"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
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
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.

