691140 - canvas print API

Status: RESOLVED WONTFIX

(Core :: DOM: Core & HTML, defect)

Description

[Andreas Gal :gal]

We should add an API to print using a canvas. Cairo already has PS/PDF backends, so this should be easy to wire up to the OS print stack.

Comment 1

[Mounir Lamouri (:mounir)]

I prefer to ask before I'm not 100% sure: you want to print to a canvas or from a canvas?

Comment 2

[Mounir Lamouri (:mounir)]

You had to read "because", not "before"...

Comment 3

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

There are some tricky parts here
 - which canvas is the "printing canvas"?  can any canvas be used to print?  what if the aspect ratio is wrong?  is the browser supposed to set up the canvas transform etc for the page-sized canvas?
 - we can't record all the draw calls made to a canvas, or canvas would be worse off than SVG.  So on printing, the page needs to redraw to a new canvas context.
 - how does the browser hand the page a new context and ask it to redraw?

Is the idea that a page would call something like canvas.print() to kick the process off?  Does the UA offer a context-menu item for printing a particular canvas?  How is the user supposed to discover that?

For the pdf.js use case, how would a user print all pages from a PDF using this mechanism?

Comment 4

[Julian Viereck]

What we need isn't a `print()` function on the existing DOM canvas element, but instead a new object that acts like the already known canvas, but instead of drawing on the screen it's drawing on pages that get printed later on.

Let's call this special canvas `PrintCanvas`. The `PrintCanvas` provides drawing commands like the DOM canvas but forwards them to a printing backend. The printing backend might be able to not have to raster down to pixel level to achieve something like 200 DPI resolutions. This is important, as creating a DOM canvas that has 200DPI resolution requires a lot of pixels and won't fit into memory on some systems (thinking about mobile browsers).

As we have a special canvas just for printing purpose, the unit "pixel" doesn't make sense anymore and we want to use something like "inch". In fact, as there is no notion of "pixels" some of the APIs like `getImageData()` as well as `putImageData()` doesn't make sense in the context of printing and shouldn't be provided by the `PrintCanvas`.

As printing isn't just about printing one page but most often about printing an entire document, there should be something keeping multiple `PrintCanvas` together. Let's call that `PrintDocument`. A `PrintDocument` contains some metadata like print-job-name etc, but also exposes an API to add instances of `PrintCanvas` to the `PrintDocument` instance.

Let's say you can add `PrintCanvas` to a `PrintDocument` only and never remove one again. With this constraint, once the `PrintCanvas` is added to the `PrintDocument` and assuming there is no reference to the JS object anymore, the object can get freed as the backend might have forwareded all the print commands to the OS already. By this memory optimization, one can create one `PrintCanvas` after the other when printing a large document, but still keep the memory usage of the browser to a mimimum.

I have some more ideas in my head on how the API for all this could look like, but for now I just want to state this and see what people think about the general idea. For pdf.js, having such an API is essential and it's a pitty that the web has never come to proper printing support.

Comment 5

[Robert Utasi [:hunboy]]

Before filing a useless dupe bug, I just ask,
what about FF20 with Adobe Acrobat Reader11 for inline pdf documents?

Mozilla currently converts the pdf document to a canvas object. without hardware acceleration the result is really crappy. With HA it uses better kerning for fonts.

But my bigger problem is the print option.

The print output looks like a fax output, with and withou HA as well. Too rude. The thin lines are dotted etc.

This should be with higher dpi with antialiasing and should fit to kerning better.

Currently as a workaround using save option, and open pdf with adobe and print from that.

Am I in a good place?

Comment 6

[Julian Viereck]

(In reply to Robert Utasi [:hunboy] from comment #5)
>
> But my bigger problem is the print option.

This is due to bug 811002.