Exciting Stuff: Firefox 19’s Built-in PDF Viewer

Firefox 19’s built-in PDF viewer is pretty exciting — not just because Firefox (finally!) has a PDF viewer, but because it’s written in JavaScript. Why is that exciting?

First, we’re always looking to extend the web platform’s capabilities. Writing a PDF rendering engine in JavaScript pushed the platform’s boundaries. We learned quite a bit while working on our PDF viewer, and we used that information to improve Firefox and the web platform in general [1].

Second, being written in JavaScript is great for security. The alternative, pursued by all other browsers with built-in PDF viewers, is to include another binary rendering engine alongside the HTML and JavaScript engines. Adding hundreds of thousands of lines of C and C++ code to render PDFs is not a good thing for security. Complex binary engines are hard to secure, and PDF engines are no exception — ask Adobe or FoxIt. Mozilla’s built-in PDF viewer will not be without vulnerabilities, but they will be vulnerabilities in the web platform that we’re already committed to securing — we’re not adding to the problem.

There’s still work that needs to be done, but Firefox and the Web took a big step today!

[1] e.g. improved font handling, canvas APIs, and JavaScript performance.

About these ads
This entry was posted in Mozilla. Bookmark the permalink.

15 Responses to Exciting Stuff: Firefox 19’s Built-in PDF Viewer

  1. robert says:

    Will it be able to print exact copies of the document? last time I tried the output looked like standard pages printed from a browser, adding the header and footer of the HTML print settings and scaling the output because the space used by the header and footer was used. I hope it is, if not I would need to ask people to disable it, because the main reason we generate PDFs is the exact clean print output

  2. Asbjørn says:

    @robert: That is my biggest issue with PDF.js as well. What is the point of a PDF viewer if it can’t print? It prints a lousy, pixellated page with HTML headers and footers. That is not good enough! PDFs need to print exactly as they are on screen – and certainly not pixellated. PDF.js is not ready for prime time – it just proves that writing a PDF viewer in Javascript remains a foolish idea!

    • Caspy7 says:

      That PDF.js is not currently excelling at printing proves that writing a viewer in JavaScript is foolish? Really? It *proves* it?
      I’m guessing you’ll then agree that should PDF.js fix the printing issues, that will prove that writing it in JavaScript is *genius*. It will be proven. Irrefutably.
      Perhaps now is a good time to mention that the printing issues are on the developers’ radar to be fixed.

    • jviereck says:

      This is not the problem about JavaScript but about HTML/CSS specs related with printing. There is no way to have native-like printing experiences when using a web page at the moment. However, as this is required for PDF.JS there is some work done at the moment to improve this. Hopefully, this will result in native-like printing experience.

  3. robert says:

    @Asbjørn the pixelation is a big problem too because printing long reports (yes a modern world must avoid printing but in reality there are legal reports that are big and must be on paper), each page is sent to printer as big bitmap, and this is not only a problem of PDF.js, PDF viewers on Java and printing complex SVG documents must resort to send a bitmap because the not all native printing capabilities aren’t exposed to the browser (or Java in the case of JVM viewers)

    A simple 20 page report take sometimes hundreds of megabytes of spool data, and the reports are pure text. IIRC PDF.js is using a Canvas so it has a bitmap representation of the document, unless a canvas that maps to printer APIs is implemented, bitmap will be generated, and being cross platform, not sure if the canvas API will map nicely to native printing API, see again Java Graphics2D lousy mapping that needs to switch to bitmaps a lot

    PDF.js is a big step and a welcomed one, but printing APIs is important too, and I think we should not need to fall back to PDF like we currently do, browsers apps should be able to generate print jobs directly

    • jviereck says:

      PDF.JS uses canvas, but it also uses the new canvas.(moz)printCallback API to avoid rasterisation the printing output. This works on OSX but is currently broken on Windows (and I think also Linux).

  4. bvibber says:

    @Asbjørn: Honestly, I can’t say that I print PDFs very often. Can’t say I print *anything* very often. Half the point of PDFs is that you don’t need paper to read them. ;)

    Having a nicely working on-screen in-browser PDF viewer is useful for me, so I say bravo. Making printing better would be nice, but it’s never come up for me in the last few months of using Firefox Aurora.

  5. Wes johnston says:

    I print pdf’s pretty often it seems like, but haven’t run into that problem. I guess I either don’t mid PDF.js’s printing, or I save and print from a bigger viewer. Having a lightweight in-product viewer is worth it to me.

  6. njn says:

    “PDF.js is not ready for prime time – it just proves that writing a PDF viewer in Javascript remains a foolish idea!”

    Whether or not the first part of that sentence is true, it has little relationship to the second half of the sentence.

  7. Felix says:

    This might be a good time to remind everyone that the Print dialog in Firefox has an Options tab where you can set the headers and footers to anything you like, including nothing at all. It doesn’t stick though, which can be annoying, but *you can remove those extras*. So what was the problem, again?

    • robert says:

      Not all platforms, on Windows Firefox does not show any options for that on the print dialog (but the global print settings works). It uses old Windows printer selection dialog by the way (I think because of Windows XP compatibility). This is a minor problem, for me the big problem is the rasterization of all pages, but as explained above by @jviereck is broken on Win and Linux only

  8. An “open PDF in external viewer” icon in PDF.js to open up the current PDF in a native viewer for form editing or printing doesn’t seem like much of an inconvenience, no? I prefer having an in-browser PDF viewer that feels instantaneous and lightweight. I don’t mind a few extra clicks for the maybe 1 out of 50 PDFs that I’m compelled to print hardcopy.

    Perhaps PDF.js needs a customizable “Send to” which allows a one-click-print to *anything* – just set up something like “acroread %f -toPostscript | lpr” or whatever CLI tool works on your platform

  9. John Thomas says:

    I dunno about the security argument, it seems that this just creates more dependency on firefox being secure, instead of splitting your vunerabilities between firefox and your pdf reader. There are pluses and minuses to this approach which can be debated, you can argue for example, consolidating the engines provides a smaller attack surface, on the other hand, you could also argue that binding the pdf reader to the browser makes it harder to secure the pdf viewer, for example by using a minimalist pdf reader to avoid vunerabilities.

    All I’m saying is that it is not a clear win.

  10. Gary says:

    I’d like a work around for viewers of my website that have decided to disable Javascript because of concerns they have for security while using it. This is common, and I believe they need to be able to use my website like anyone else.

  11. Jeff Walden says:

    John, it’s not really creating more dependency on Firefox being secure. Anything pdf.js does, can already be done by a regular website. (Or maybe very nearly anything — I’m not sure if it does anything with privileged APIs or not. Whatever’s done with any, should there be anything, is minuscule compared to what a PDF rendering engine implemented in C++ does through its own effectively privileged APIs.) So aside from very little bits like mozPrintCallback, mentioned here already, there’s no new dependency. And the amount of additional complexity in mozPrintCallback is peanuts compared to the amount in an entirely new rendering engine.

    Gary, we’re working on fixing the JavaScript thing. I’m not sure about the timeline, exactly, but this could be fixed in a few releases or so. (Some patches to improve a similar situation have been landing recently, and they might help pdf.js too. I don’t know for sure.) I do believe we have preferences (hidden, or maybe exposed) that can flip pdf.js off. And if that’s not a desirable workaround, you can always send the files with application/octet-stream as their MIME type, to trigger download-as behavior.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s