Mozilla Updates HTML5-based PDF Renderer
Mozilla has just released a new version of the pdf.js, an HTML5-based PDF renderer that displays PDFs directly in the browser.
The latest version of the software, which was firslty released by Mozilla's developers a couple of weeks ago, is loading Type 1 fonts, in what the developers described as a very challenging task.
In addition, pdf.js version 0.2 is loading TrueType fonts properly, the shadows under the rounded boxes are masked images, and the dashed lines are drawn using a new API developers have added to Firefox's canvas.
And last but not least, the user interface in version 0.2 is much more usable and than in the initial version.
Displaying PDFs directly in the browser would definitely improve the user's experience. There are literally millions of PDFs floating around the web, and on many devices loading PDFs switches to a different application (e.g. Preview on OS X and PDF View on Android). Also, external PDF readers and many plugins don?t support important PDF features well, including content links and fetch-as-you-go (HTTP range requests).
External readers and plugins are also forced to reinvent their own user interaction paradigms, meaning for example that users might scroll HTML pages in one way with one set of heuristics in the browser, but a totally different way in an external PDF reader.
The traditional approach to rendering PDFs in a browser is to use a native-code plugin, either Adobe's own PDF Reader or other commercial renderers, or some open source alternative (e.g. poppler). From a security perspective, this enlarges the trusted code base, and because of that Google's Chrome browser goes through quite some pain to sandbox the PDF renderer to avoid code injection attacks. An HTML5-based implementation is completely immune to this class of problems.
Mozilla intends to use pdf.js to render PDFs "natively", within Firefox itself and make it compatible with all HTML5-compliant browsers.
"We want to prove that a competitive HTML5 PDF renderer really is feasible, and not just fun talk. Many more hard problems remain, but we haven?t come across any so far that are so much harder than what we?ve already solved to make us rethink the viability of pdf.js,"
For the next release, Mozilla has two big goals: first is to continue adding features needed to render PDFs. The next target is a bit more ambitious: pixel-perfect rendering of the PDF 1.7 specification itself. Work has already begun on this, during the stabilization period for the 0.2 release. Second is to improve pdf.js's architecture. This itself has two parts: use Web Workers to parallelize computationally-intensive tasks, and allow pdf.js's main-thread computations to be interrupted to improve UI responsiveness.
For more information, read Chris Jones' blog post here.
In addition, pdf.js version 0.2 is loading TrueType fonts properly, the shadows under the rounded boxes are masked images, and the dashed lines are drawn using a new API developers have added to Firefox's canvas.
And last but not least, the user interface in version 0.2 is much more usable and than in the initial version.
Displaying PDFs directly in the browser would definitely improve the user's experience. There are literally millions of PDFs floating around the web, and on many devices loading PDFs switches to a different application (e.g. Preview on OS X and PDF View on Android). Also, external PDF readers and many plugins don?t support important PDF features well, including content links and fetch-as-you-go (HTTP range requests).
External readers and plugins are also forced to reinvent their own user interaction paradigms, meaning for example that users might scroll HTML pages in one way with one set of heuristics in the browser, but a totally different way in an external PDF reader.
The traditional approach to rendering PDFs in a browser is to use a native-code plugin, either Adobe's own PDF Reader or other commercial renderers, or some open source alternative (e.g. poppler). From a security perspective, this enlarges the trusted code base, and because of that Google's Chrome browser goes through quite some pain to sandbox the PDF renderer to avoid code injection attacks. An HTML5-based implementation is completely immune to this class of problems.
Mozilla intends to use pdf.js to render PDFs "natively", within Firefox itself and make it compatible with all HTML5-compliant browsers.
"We want to prove that a competitive HTML5 PDF renderer really is feasible, and not just fun talk. Many more hard problems remain, but we haven?t come across any so far that are so much harder than what we?ve already solved to make us rethink the viability of pdf.js,"
For the next release, Mozilla has two big goals: first is to continue adding features needed to render PDFs. The next target is a bit more ambitious: pixel-perfect rendering of the PDF 1.7 specification itself. Work has already begun on this, during the stabilization period for the 0.2 release. Second is to improve pdf.js's architecture. This itself has two parts: use Web Workers to parallelize computationally-intensive tasks, and allow pdf.js's main-thread computations to be interrupted to improve UI responsiveness.
For more information, read Chris Jones' blog post here.
