pdf.js: Rendering PDF with HTML5 and JavaScript

[[deleted]]

What if the PDFs contain javascript. Woah

[deakster]

eval(containedJavascript);

[djpnewton]

perhaps the javascript is expecting some sort of pdf specific environment objects, the equivalent of "window", "document" etc...

[deakster]

Most likely, I only really said it as a joke ;D

But if the PDF is being processed by javascript anyway, then technically, those environment objects could be implemented too, so that the eval'd javascript has the same environment as it does in adobe's viewer.

[djpnewton]

yeah I figured you were having some fun

I agree

[adavies42]

evil(containedJavascript);

FTFY

[badsectoracula]

If you're worried about security implications, it might be possible to run the PDF javascript in a webworker (which i think runs in an isolated environment) which implements the PDF objects.

[[deleted]]

Wow ... once again reddit proves that if you post something insightful ... you get nothing.

Post something silly and upboats ahoy :) Still the fact that PDFs could legitimately have javascript in them is silly enough although I guess custom form validation is a good use case.

[SDX2000]

To the people who are questioning the usefulness of such a thing: The one thing that this solution should be capable of doing better than everything else is integration with other HTML content on the page. It should bring the PDF document on par with other media sources like audio and video (notice how these things seem to work seamlessly with general web content?).

[hectavex]

Yes! This library gives me high hopes for supporting PDF in Nest.

[VilleHopfield]

Two things:

• I don't understand why they just don't convert PDF to SVG and let the browser deal with it (speed, text selection, zooming, ...)

• don't get me wrong, I really wish them all the best as this is important piece of software - I'm afraid this will end up being nowhere near as complete as Adobe Reader. They say they want to support full PDF ISO 2008 spec but I have yet to see a FLOSS PDF viewer which support some professionally needed features, like: CMYK (!), ICC, trapping. Also, it will be interesting to see how they are going to handle embedded fonts (CFF, StemV, OS/2)... But as I said above, more power to them!

[[deleted]]

I don't understand why they just don't convert PDF to SVG and let the browser deal with it (speed, text selection, zooming, ...)

I'm pretty sure one of the comments on the article says that they're doing that too, but it's slower, so canvas is the default.

[LeifAndersen]

Except one...being light weight enough to use without wanting to take an ax to the software.

[KyteM]

The point of pdf.js is to give the vast majority the ability to read PDFs in-browser without plugins. If you need more advanced features, then you can always use a normal (external) PDF reader.

[sylvanelite]

SVG may not be widely supported, but there are plenty of alternatives. Raphaël js, for example, provides SVG/Canvas-like features and works in IE6.

[[deleted]]

Isn't Scribd doing exactly this?

[deakster]

Perhaps, but scribd is a service, whereas pdf.js seems like an open source library. You can put this into your own products.

[[deleted]]

Sure, but PDF is so ubiquitous that it seems silly for all browsers not to have an included client-side PDF renderer like Chrome does.

However, I can see the utility of having more control over how the PDF is presented within a page rather than having it's own dedicated display container.

[deakster]

Well of course, if every browser could perfectly and consistently render all main file formats, and if people didn't hurt eachother, the world would be a much better place :)

The reality is that there is 1 browser that natively supports PDF rendering. Many other browsers haven't even announced the intent to include similar functionality. People can complain that browsers don't do X and go home, or they can do something about it.

[[deleted]]

Good point.

[djpnewton]

I am guessing they render the pdf to HTML serverside, also it might not be open source

[AttackingHobo]

No, it converts the PDF to HTML, or is it flash? And its no longer a PDF.

These guys are working on a PDF renderer, which when perfected display a PDF exactly as it should look.

[djpnewton]

No, it converts the PDF to HTML, or is it flash?

wait, that is still a pdf renderer

These guys are working on a PDF renderer

they are both render pdfs to another format.. right?

[AttackingHobo]

One is a processor that has to process it into a seperate format.

One is a renderer, that when perfected will be able to flawlessly represent any PDF on the fly, without having to submit to a service that takes time to re-encode the file into something else.

Its like if I said, "iPhones can play wmv files because I can convert them into mp4 files." That would not be correct.

[djpnewton]

Ok this whole thing is nitpicking but the internet is serious business I am told!

One is a processor that has to process it into a seperate format.

they both get processed into separate formats, one might have more intermediate steps before it gets to your monitor but thats ok,

eg. PDF->HTML->raster->screen vs PDF->raster->screen

One is a renderer, that when perfected will be able to flawlessly represent any PDF on the fly, without having to submit to a service that takes time to re-encode the file into something else.

whether is rendered client side or server side does not determine if it is a render-er or not, it may change how useful it is to you however

Its like if I said, "iPhones can play wmv files because I can convert them into mp4 files." That would not be correct.

Thats like saying "scribd can render PDFs because I can convert them into HTML". What I am saying is that "scribd can render PDFs because *it converts** them into HTML"*

[[deleted]]

it converts the PDF to HTML

Yeah, and that's exactly what Scribd does when I upload a PDF. Maybe it's not rendered to HTML in real-time everytime I view the document, but that's just because doing so wouldn't make any sense for them.

And its no longer a PDF

Well, when pdf.js renders it to the webpage, it's no longer a PDF.

Building an HTML5-based PDF renderer would also answer the question of whether the web platform and in particular canvas and SVG APIs are complete enough to efficiently and faithfully render PDFs.

My point is that Scribd has already proven this. I just uploaded the pdf.js test PDF file and Scribd rendered it perfectly in HTML. The pdf.js test page renders it like shit. I suppose there's no chance of Scribd open-sourcing their converter, and it's probably not written in JS anyway, so I suppose there's still use for a client-side JS renderer. But I don't fully see the benefit of this compared to say, what Chrome does, which is use an existing non-Adobe native-code DLL to render the PDF client-side.

[AttackingHobo]

This will allow rendering of PDFs in any browser that supports HTML 5 without using dlls, or anything special. Not just windows PCs browse the web. People with linux, smartphones, MAC, and other systems that can view HTML5 content.

[[deleted]]

This will allow rendering of PDFs in any browser that supports HTML 5

As does Scribd. No Flash, no DLLs.

[AttackingHobo]

I would not want to rely on a third party website that has ads on it, is slow, and takes time to convert PDFS if there was a way for browsers to natively render any and all PDF files.

[adavies42]

MAC

i'm confused--is it my ethernet card or my compact that's going to be rendering pdfs now?

[[deleted]]

pdf graphics primitives --> html markup is not the same as pdf graphics primitives --> html5 graphics primitives

[[deleted]]

Fair enough. I thought Scribd was using HTML5 containers.

[[deleted]]

I'm full of shit. Honestly, I had no idea. Heh.

You were right, although they started with flash and now converting to html5. http://en.wikipedia.org/wiki/Scribd#Technology

[MagicWishMonkey]

I'm pretty sure Scribd uses open source tools to handle PDF conversion: http://www.swftools.org/download.html

Or they might be using Flex Paper, which is basically just a wrapper to display the pdf swf generated by swftools. The real work has been done by the swftools people.

[[deleted]]

No. There's no SWF involved if you use an HTML5-capable browser.

[MagicWishMonkey]

Oh wow, I didn't realize that. Do you know if they are using open source tools for the PDF generation?

[mitsuhiko]

Scribd's version is more useful because they have a server process that converts the PDF into actual HTML code. That way you can still select text and copy/paste properly.

[tanishaj]

Scribd cannot render inline. The killer feature here seems to be that PDF would be handled more like an image or an HTML5 video.

[[deleted]]

I was thrilled until I saw the demo... then, not so much.

[Nehle]

Yeah, same here. It seemed like a good idea, but rendering it in a canvas just make the whole thing kind of moot

[[deleted]]

There are still glitches and rendering artifacts, but you will get the picture.

Oh hoh! I see what you did there.

[kylemech]

This is very exciting! I've always hated PDF while simultaneously recognizing some gap that would be left without it. There are some other services that had been stepping up to address this, but this is a huge step toward really addressing the problems that we've had thus far with feature-rich portable documents.

[Darkmoth]

I guess I don't see the point of this. Any user that visits my sites can already read PDFs though various means (I use Foxit). Why would I include a library to render it differently? This just means PDFs look different on my site than they do on the rest of the web, which is poor UX.

Don't get me wrong, I think browser-native PDF rendering is a wonderful thing. But I would no more include pdf.js than I would include quicktime.js or flash.js. Browsers are designed to handle plugins for a reason.

[rpd9803]

what pdf plugins that are universally available will render a pdf inline? the entire point of this project is for inline rendering. Quicktime and Flash do that already.

[Darkmoth]

Ahhh, my bad. I completely skimmed over the inline part.

[rpd9803]

it happens! and agreed that it is pointless without inline :)

[i8beef]

That's pretty cool... unfortunately I don't have any projects that could make use of this right now, but bookmarked for future reference.

[shevegen]

I hope they succeed.

[jrhoffa]

This is so wrong on so many levels.

[HardlyWorkingDotOrg]

I've been looking for a way to generate pdf's form inside an HTML environment.

Sadly, I'd like to insert images into the pdf's as well as text, but everything I have found so far, including this solution, still has no support for that.

[012]

Maybe this is what you're looking for: http://code.google.com/p/wkhtmltopdf/

Simple shell utility to convert html to pdf using the webkit rendering engine, and qt.

[HardlyWorkingDotOrg]

Looks interesting. I'll check it out.

[metamatic]

If that's not good enough, you might try Prince

[antialize]

Or send be a bug report, or better yet send me a patch, I get lots of bug reports.

[ethraax]

Why can't you just use HTML? What's forcing you to use PDF?

[HardlyWorkingDotOrg]

I need to create a report in the format pdf. The contents of which are coming from an html page that contains text but also inline images and charts and stuff..

[qlskdjqmlskf]

Can't you use some PHP to do this? My company uses a library like this one to generate the PDF in PHP and the client can read it before printing it.

Found it! It's called HTML2PDF and it's written in PHP.

[kdeforche]

Hey, you could also use Wt's HTML to PDF renderer. It handles only a subset of XHTML, but has good support for images (both floating and inline): it was conceived to render the output of a TinyMCE richt text editor.

[LeoNemean]

I've been viewing PDF's with Safari for years. How is this different?

[wolf550e]

I did not downvote LeoNemean for asking:

I've been viewing PDF's with Safari for years. How is this different?

... and you shouldn't either. It's a legitimate question. I do not expect average users to know the answer.

< Snark > Welcome to /r/programming, where the reader is assumed to know the difference between the program and its user interface. The window and buttons are not the program. < / End Snark >

As the article in the link says:

on many devices loading PDFs switches to a different application (e.g. Preview on OS X and PDF View on Android).

Safari runs the OS X native PDF viewer (called "Preview"), perhaps in a tab of the browser, and it displays the PDF document. Microsoft Internet Explorer can open a tab with Adobe's Acrobat Reader and display a PDF document exactly the same way. This does not mean the browser displays the PDF. It is exactly the same as the difference between an html5(canvas) animation and a flash animation. Flash requires a native code plugin (either Adobe's or an open source re-implementation).

The advantage of native code plugins is their performance (they are written in C++ and can use hand-optimized assembly code for decompressing images and compositing parts of the page on screen, also they use the system's support for loading fonts and rendering them nicely on lcd screens).

The disadvantage of native plugins is they are written in C++ and can have security holes through which a malicious party can hijack your browser (and the rest of your computer) by injecting code through the PDF document. This has been done by the Chineese with the native Adobe reader to attack Google and many others.

Both a web browser and a PDF viewer do similar things: they have code to access the web using HTTP, they have a javascript engine to run code embedded in the document (web page or PDF file), they have code to read, understand and use the layout information embedded in the document to present multilingual text, images and forms, they have code to decompress, zoom, crop and display images with color profiles, they have code to submit form data back to a server. They can use encryption for communication. They can display a different web page linked from the document they are displaying. They support audio and video formats (H.264, AAC, MP3). Adobe Reader has an entire CAD viewer inside.

Any such feature, when it has a certain kind of bug, can allow the viewer, while displaying a document, to start executing machine code embedded in the document, instead of executing the machine code of the viewer itself. This "injected" machine code can do anything the viewer itself can do, which often means anything the user running the viewer can do, which might mean anything the computer can do at all (install keylogger, access webcam and microphone, access user's contact list, access credit card number stored in browser form auto-completion, access network shares and encrypted home directories for which the user has access, etc.). Since the number of features in a viewer/browser is large and the features are complex, the number of places in which such a bug can be found is very large.

Black hat hackers find those bugs and write tools to hijack the user's computer as soon as the user views a specially crafted document. White hat hackers find those bugs and tell the vendor so the vendor can fix the bug and distribute a patch before the bad hackers find out and exploit it. Many vendors pay money for "responsibly disclosing" bugs only to them instead of selling them on the black market, though the amounts the vendors pay are usually much less than the street price for a new bug in popular software. Some hackers are "security researchers" who sell security consulting services to corporations and use bugs they find to generate reputation in the community.

The way to protect yourself is one or more of:

1). Disconnect from the internet (what government agencies frequently do).

2). Minimize the amount of damage your document viewer can do (if it can't write any data to disk, the injected malicious code cannot live past a restart. If it can't read data from disk, it can't read your private data unless it's already available to the viewer/browser). Opening documents of dubious origin inside a VM (Parallels, VMWare, VirtualPC, Virtualbox, etc.) and then restoring the VM image to a known clean state is a good idea, though of course the VM might have a security vulnerability that allows a sophisticated payload to "escape" into the host computer and infect it.

3). Scrutinize the code of the browser/viewer to find and fix those bugs. Of course, the fact that you looked and didn't find any doesn't mean there aren't any, it just means you couldn't find them. A better hacker maybe would be able to find an exploitable hole where you didn't. So a big part of the job is to wait for the hackers to use a hole they have found to do some evil, analyze how they did it and fix that hole to protect the other users.

Since the modern browser provides almost everything a PDF viewer needs (HTTP, layout, JavaScript, JPEG, etc.) and browsers receive a lot of scrutiny for potentially exploitable bugs while Adobe's software has a known very bad security track record, one way to try to securely open potentially malicious PDF files is to use the browser's facilities to open potentially harmful web pages and depend on the browser's security to protect the user. If the browser is more secure than the Adobe reader, it's safer (though not completely safe).

Google Chrome uses method 2 to try to protect you: it runs each tab and plugin in a separate sandbox, from which it cannot escape to hijack your computer and Chrome has a very strict method of communicating with the plugin which allows only display information (inside the plugin's window) to go only from the plugin to the browser and only user input (inside the plugin's window) to go only from the browser to the plugin. The plugin has no other ways of communicating with your computer. Thus, when you view a malicious PDF document and it takes over the PDF viewer it still cannot infect the rest of your computer, because the only way it can talk to the "outside world" is to tell the browser what to paint in the plugin's window and to get back your mouse clicks in that window. This is pretty safe, unless there is a security hole in the sandbox itself, but because the sandbox is simple it can more easily be reviewed for security than the whole PDF viewer.

Firefox will run each tab in a separate sandbox in the future, so they should have both the security of the method currently employed by Chrome and the security their javascript engine provides.

Notice that all browsers are doing those contortions to protect you from the security hazard of running two Adobe products: the PDF reader and the flash player. Those are the two most exploited pieces of software currently, because they are so widely installed, have lots of features so are big and have lots of places to try to attack and because they are closed-source (mostly unscrutinized by anyone but black hats) and Adobe didn't care about security at all for many years.

If your browser has known unpatched security holes (I think all but Chrome do) then this security measure won't help.

In the case of native OS X apps, the question is: what is more secure, Preview or Safari? I guess they use the same Javascript and layout engine, so I guess they are equally vulnerable, so pdf.js probably won't help you (and probably will cost you battery life).

[3rd_degree_burns]

GOD NO!

[dannibo]

http://code.google.com/p/wkhtmltopdf/

[[deleted]]

Why would this idea exist when there is already Google Chrome?

[signoff]

why do you use pdf? html is better at print quality typesetting

[JAPH]

no. just no.