Andreas posted a general overview of pdf.js. I’d like to briefly cover some more-technical parts of the renderer.
The rendering of fonts embedded in PDFs using web technologies is a big enough topic to merit its own blog post. A post might eventually appear on Vivien’s, but if not, somewhere else ;).
There are several ways to write a PDF renderer on top of the web platform; pdf.js’s current implementation, drawing to a <canvas>, is just one way. We chose canvas initially because it is (should be) the fastest way for us to draw to the screen. We want the first-paint of pages to be quick so that pdf.js startup feels zippy, and users can start reading content ASAP. Canvas is great for this.
Canvas has problems though. First, it’s missing many features needed to render PDFs. We’ve starting adding some of these to the web platform, when it makes sense to do so, and there’s more to
come. A second, and much bigger problem, is that while canvas’s immediate-mode design allows us to render with minimal overhead, it means that the user agent doesn’t have enough information to allow users to select text, or navigate using accessibility interfaces (through a screen reader, e.g.). Printing canvases with high fidelity is another issue.
The web platform already offers a (potential) solution to these problems, however: SVG. SVG is richly featured, retained-mode, and has its own DOM. In theory, user agents should have text-selection, a11y, and printing support for SVG. (If they don’t, it needs to be added.) So, SVG provides (in theory) the features missing from <canvas>, just at a higher cost in the form of more overhead.
Putting all this together, we currently plan on doing a fast first-paint of pages using canvas, concurrently building an SVG document for the page in the background, and when the SVG document is ready, switching to that. Or if that doesn’t work well, we could implement text-selection (and hopefully a11y) in pdf.js itself, on top of canvas, possibly creating new web APIs along the way. Or if, say, font loading dominates the critical path to first-paint, we might only use SVG and forget canvas. It’s great to have these options available.
There’s a ton of work left on pdf.js, from implementing features to improving the user interface to exploring crazy ideas (like for example using WebGL to speed up rendering). The project is open and the code is libre: we’d love for you to get involved! Have a look at our github and our wiki, or talk to us on IRC in #pdfjs.