Add printing support

[jviereck]

No description provided.

[joneschrisg]

Goals

• output PDF pages at printer resolution. Ideally this means directly sending PDF or PS commands to the printer. If we can't do that directly, do it indirectly by using SVG printing support in browsers, e.g.
• only output the PDF pages. No browser-added headers or footers.

The big to-do item is to figure out what existing web APIs let us do. I've heard there's some kind of "onprint" event or something, but I don't know what we can do with it. After that, we can make a best-effort implementation with what we have, and then figure out what web APIs to add.

[joneschrisg]

Olly Pettay from Mozilla pointed out that the event we can listen for is "beforepaint".

[saebekassebil]

Couldn't this be solved with a stylesheet, which just removes everything but the page canvases?

[joneschrisg]

Not really. We don't keep canvases for all pages around all the time because that would consume a huge amount of memory. We also need to rerender the canvases at output resolution, not screen resolution. SVG would make that a non-issue, but we would still have a problem trying to print >1000-page PDFs.

[notmasteryet]

Using something like Internet Printing Protocol might help (?) If the "printer" supports PDF we can send it as is, otherwise PNGs can be generated and sent to the server.

(https://bugzilla.mozilla.org/show_bug.cgi?id=680617)

[notmasteryet]

(http://groups.google.com/group/mozilla.dev.pdf-js/browse_thread/thread/37c83dfdecffd192#)

[jviereck]

Couldn't this be solved with a stylesheet, which just removes everything but the page canvases?

Just printing the canvas isn't enough by far. The resolution of the rendered canvas compared to the resolution (200dpi?) for printing is far to low. Either a really bit canvas is rendered to solve this issue, or we come up with some proper Web Print API, which I'm voting for. I can imagine a lot of applications like MS's Office 365 or Google Docs that like to have 100% perfect printing support without any workaround.

[devongovett]

YES! A web printing API would be absolutely fantastic for many applications. Right now, web apps have virtually no control over the print output that they produce with browsers adding ugly headers and footers by default, and difficulty controlling print layout, page breaks, etc. A low level web print API that just let developers output raw graphics commands with an API similar to canvas, but with additional APIs for controlling page breaks would be awesome here.

[devongovett]

Oh, and I think a potential WebPrint API should be a little higher level than just "send postscript commands to the printer". :P A nice API like canvas has, perhaps just extending the canvas API to support printing, would be pretty awesome. For example, a potential API that I just made up would be:

window.onprint = function(event) {
    var ctx = event.printerContext; // basically a canvas context with a few extra methods...

    // draw in ctx...
    ctx.insertPageBreak();

    // draw the next page...

    ctx.finalize(); // or something... actually sends it to the printer
}

window.print(); // brings up print dialog as usual, and prints using context instead of page

That is just one idea, but let's get the ball rolling on this one. It would be awesome for the web! :)

[jviereck]

I've analysed the current state of printing. See here:

https://plus.google.com/u/0/115228539776721208421/posts/LbVDmfALeey

The comment by Eugene expresses very well what I was concerned about and I think he is right. For most use cases, a not canvas-based print solution for the web would be better, as styling a page/table/any content using HTML&CSS is way easier then implementing all the drawing, text breaks etc. in JS, although the browser knows way better how to do it. (Also, note that the +1 comes from Paul Irish.)

A WebPrintAPI as I have it in my mind fits the needs for PDF.JS, but I don't think there is much sense in implementing & standalize an API that is not useful for other use then PDF.JS.

Therefore, I think I take a closer look at CSS3 Paged Media and try to figure out what subset needs to get implemented to fit the requirements for PDF.JS. Also, once that's figured out, I want to ping Roc and discuss what he thinks about it/how to implement the missing stuff.

Not using the WebPrintAPI idea implies that the rendering needs to be done using SVG to get good looking printout. Right now I got the first page of the tracemonkey paper working on a very simple SVG backend for PDF.JS and the performance is not that much worth then in canvas.

Does that sounds reasonable?

\cc @brendandahl, @arturadib, @wfwalker

[GPHemsley]

I support the push for better printing support in the browser, even independent of its effect on the progress of printing support in pdf.js. So I'm all for trying that route.

[devongovett]

I'll say what I said on Google Plus here just so everyone sees it:

CSS and HTML are good high level tools, but honestly I think we need both low level APIs and high level ones so we can properly fill both use cases. I would love a WebPrint API that allowed me direct, pixel perfect control over my printed output rather than leaving that up to the browser. CSS will be good enough for most people, but there are some use cases for a lower level API as well. PDF.js is one of them.

Honestly, the real reason why I wrote PDFKit (my PDF document generator), is so that I could generate nice looking printed documents from an app I was working on. I originally tried doing things with CSS paged media and HTML but had all sorts of problems, namely getting things to lay out properly and issues like not being able to programmatically hide and show the headers and footers with the webpage URL in them that browsers put there, etc. So I wrote PDFKit, and generate the documents server side. The user then has to download the PDF and print it from there. This works but it is very cumbersome for the user, and for the developer.

I don't think there is any problem with supporting both low level and high level APIs in the browser in general. Most people will use the high level one, but for certain use cases low level APIs are really useful when we want to do really custom things that the standard hadn't thought of yet. Anyway, just my two cents!

[jviereck]

Based on the feedback and some other discussions I've started to scratch what a WebPrintAPI could look like. See this post:

https://groups.google.com/forum/?fromgroups#!topic/mozilla.dev.webapi/2J4wigFiCF8

Future discussion about the API will happen on the mailing list.

[jviereck]

Opened bug 745025: https://bugzilla.mozilla.org/show_bug.cgi?id=745025

Attached is a first iteration of the mozPrintCallback implementation.

[saebekassebil]

Printing support has been added - Should this be closed?