Hi,

the PDF.JS team is dealing with printing support on the web. I looked at what's currently possible with the browser and shared some thoughts about it here:

   https://gist.github.com/1953505#file_gistfile1.md

There are some comments on this G+ post:

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

Based on that feedback, I've started on a new WebPrint API proposal, that you can find here:

    https://wiki.mozilla.org/WebAPI/WebPrintAPI

There isn't too much yet. So far I have scratched out the basic API and started some very basic implementation work. However, I hope this is enough to get some discussion about this proposed API going and I'd like to get some feedback what people think about it.

Best,

Julian

PS: This API was proposed on the WebAPI mailing list. I was told to share the API proposal on this list as well as some layout people might have an opinion on this as well and don't follow the WebAPI mailing list.

On Wed, Mar 14, 2012 at 9:02 PM, Julian Viereck <

We need to implement the CSS3 stuff anyway. How about:
-- Implement CSS3 Paged Media sufficient to make headers/footers and
margins go away, select page orientation and size. That shouldn't be too
hard.
-- Add an event to canvas that fires per-page during printing to render
that canvas content while we're printing the page it's on. This event would
provide a special canvas context that's compatible with the 2d interface
but internally renders at higher resolution (or possibly emits PS/PDF
directly).
Then you could create a print document that's just a series of canvases,
with the appropriate CSS to remove headers/footers/margins etc, and as we
print each page we'll run the callback on each canvas to paint it more
accurately. Any temporary resources could be thrown away after painting
that page.

Rob
--
“You have heard that it was said, ‘Love your neighbor and hate your enemy.’
But I tell you, love your enemies and pray for those who persecute you,
that you may be children of your Father in heaven. ... If you love those
who love you, what reward will you get? Are not even the tax collectors
doing that? And if you greet only your own people, what are you doing more
than others?" [Matthew 5:43-47]

On 03/14/2012 02:02 PM, Julian Viereck wrote:

A few small comments:

* Instead of forbidding px, define 1px = 1/96in
* similarly, ctx.putImageData should scale to 1px = 1/96in, unless the
image object has embedded resolution information, in which case it
should be honored
* .getImageData should, if possible, produce a raster at the true
printable resolution
* (0,0) should be the top left hand corner of the print area, not the paper
* CMYK opens a huge can of process worms (which the GCPM language you
linked to, doesn't even *begin* to cover); avoid for now
* No matter what the document does, Print Preview needs to be capable of
showing an as-accurate-as-possible WYSIWYG rendition; it's not clear to
me whether this is true in your proposal

zw

On 03/14/2012 03:26 PM, Robert O'Callahan wrote:

That's clever, I like it.

zw

IIUC you're asking that we implement the default behavior for CSS3 Paged Media margin boxes:

Margin boxes have an initial value of zero for padding, border and margin. The default height of top boxes is the value of the page box's top margin. The default height of the bottom boxes is the value of the page box's bottom margin.
The initial value for 'content' is 'none'. The initial 'width' and 'height' of margin boxes is 'auto'.

http://www.w3.org/TR/2006/WD-css3-page-20061010/#populating-margin-boxes

In other words, we won't be rendering any content for headers or footers.

You're also asking that we implement page size, and portrait vs. landscape:
http://www.w3.org/TR/2006/WD-css3-page-20061010/#page-size

Will that do the trick for the pdf.js use cases?

-- Jet

We need to implement the CSS3 stuff anyway. How about:
-- Implement CSS3 Paged Media sufficient to make headers/footers and
margins go away, select page orientation and size. That shouldn't be too
hard.
-- Add an event to canvas that fires per-page during printing to render
that canvas content while we're printing the page it's on. This event would
provide a special canvas context that's compatible with the 2d interface
but internally renders at higher resolution (or possibly emits PS/PDF
directly).
Then you could create a print document that's just a series of canvases,
with the appropriate CSS to remove headers/footers/margins etc, and as we
print each page we'll run the callback on each canvas to paint it more
accurately. Any temporary resources could be thrown away after painting
that page.

(I've forgotten to do a reply-all, such that some of the conversation between me and Rob didn't made it to the mailing list. I include my reply + Robs reply + my new reply to rob in this post. Sorry about this.)

Is the browser blocked during rendering all the pages as things are implemented right now or does the browser UI gets responsive during rendering the individual pages?

I'm sorry - I don't understand what you mean by "--- with any solution"?

Julian

Okay.

The idea is to give developers the choice of render parts of the page with less details. E.g. if there is a complex graphic but it doesn't take up too much space in the preview, it might be worth showing a placeholder graphic compared to render the complex graphic and take a few seconds for that afford.

Does this answer your question?

Julian

Together with a new callback for printing canvas graphics, this looks very promising.

I'm still a little bit concerned about blocking the UI for printing (esp. for large documents which is common if you print some PDF), the corresponding memory usage and if page preview will scale for large documents.

Julian

Together with a new callback for printing canvas graphics, this looks very promising.

I'm still a little bit concerned about blocking the UI for printing (esp. for large documents which is common if you print some PDF), the corresponding memory usage and if page preview will scale for large documents.

Julian

On 03/15/2012 07:52 AM, julian.vier...@googlemail.com wrote:

Agree.

The current printing logic (start with layout/printing/nsPrintEngine) is
a two-phase operation.  First we reflow the entire document with
pagination, uninterruptibly; second we paint each page in succession,
allowing the UI to process events but only in between pages.

This is already a cause of significant jank, and it would be great to do
something about it; but it might be quite a lot of work.  I had a
conversation with Boris about this the other week, I think in
dev-platform; you might find it instructive.

Right now, execution of page JS is suspended for the course of the print
operation.  (Within the cloned document, that is.  Although there are
still comments within layout/printing that suggest that the
document-cloning project is incomplete.)  If we want to allow the UI to
process events *during* the painting of one page, your "paint this
canvas now" API is going to need some sort of interruptibility.  Off the
top of my head I don't know what that ought to look like.

The current print preview arrangement is sort of an afterthought to
normal printing.  I don't know what its memory requirements are like.

Basically what I'm saying is there's a lot of work to be done here but
it's work we need to do anyway :)

zw

 > Right now, execution of page JS is suspended for the course of the print

If you say the JS is suspended, is it still able to call a callback on the canvas element that does the drawing while the print is taking place?

On 03/15/2012 12:08 PM, julian.vier...@googlemail.com wrote:

Nope.  No page JS can execute while we're in print layout mode (if I
have understood what nsPrintEngine is doing correctly).  That would have
to change.

zw

On 03/15/2012 05:54 PM, Zack Weinberg wrote:

Well, it is not expected that any script runs in the cloned document.

IIRC, the only thing that is incomplete is that plugin handling could
be better.

print preview is pretty simple. You just create a paginated
prescontext/layout for the cloned document, and show it otherwise like
a normal document.

On 03/15/2012 09:08 PM, julian.vier...@googlemail.com wrote:

JS in the cloned document is suspended. JS in the cloned document never
runs. The callback would run in the original document, and possibly
update the cloned document (if needed).

If I get that picture right, here is what would happen during printing:

1) the document is cloned, printing is started on the cloned document
2) while printing the cloned document, a canvas element is detected
3) for this canvas in the cloned document, the canvas object in the original document is looked up
4) on the original canvas, it's checked if the canvas has a callback specified doing the special print drawing
5a) If true: this callback is called on the original document passing over a context that knows how to render directly to the printer
5b) If false: the canvas data as available in the cloned document is printed (like it is done right now)

For step 3, is it possible to find the corresponding "original" canvas based on the canvas in the cloned document? Is it possible to call a JS function on the original object like required in step 5a)?

How much is this possible if the original document structure has changed already?

Also, the callback is called within the original document, that might have changed already compared to the cloned document. This might be confusing for developers. Is this a problem or just something to tell the developers that this might be the case and it should be all fine?

On 03/18/2012 11:03 PM, julian.vier...@googlemail.com wrote:

Right now no, but that would be easy to add. Just add a member variable
to nsHTMLCanvasElement and make it point to the original element in
nsHTMLCanvasElement::CopyInnerTo

That should be easy.

In general cloned document doesn't really care about the original
document. That was the reason for cloning; original document can
continue to execute JS etc, and clone will be printed.
So, if there is a strong reference from cloned canvas to the original,
everything should just work fine.

We may want to add some new events, since afterprint fires too early
for this stuff. There could be some asyncronous afterprintprocessed event.

Or, hmm, could we add some mapping from canvas to callback, but not
really register the callback to canvas?
Something like:
window.setAlternativePrintHandler(somecanvasElement, callback);
Then define that so that right after beforeprint event the callback is
stored in a list which will be called during printing, regardless
whether the original canvas is in the document anymore.

The special print handler belongs to the canvas element. Therefore it should be defined directly on it I think.

Actually, we are not interested in anything more then keeping a reference to a JS function that was defined on the canvas for the print callback. A link to such a function could be created during the CopyInnerTo function call. Then we can be sure it's there when calling the function while printing, although the canvas element itself might got removed from the original document already.

Does that make sense/is possible to implement?

On 03/19/2012 02:00 PM, julian.vier...@googlemail.com wrote:

In practice you need to keep the element alive too, in which case the
callback stays alive.

After thinking about the proposed ideas in Robert's first reply, based on the feedback to my raised questions (you guys are awesome, thanks!) and talking to some other people, I think it's best to drop the WebPrintAPI proposal and go with what Robert proposed.

That requires two things to get implemented in Gecko:

i) Implement a subset of CSS3PagedMedia to set the margin (at least the case = 0 to hide all the header/footer) and the page size.
ii) Implement a new callback on the canvas element that is called during the actual printing to print directly to the printing backend.

What's the best way to get the implementation going?

For i), there seems to be a bug already: https://bugzilla.mozilla.org/show_bug.cgi?id=115199

I tried to understand what the patches are doing and couldn't figure it out for most parts. For i), is the way to implement this by continue working on bug 115199, or should there be a new bug that tries to implement only a very dump subset of the CSS3PagedMedia, such that one can set the margin to 0 and the page-size and that's it?

So far I have some basic understanding about how the printing stuff works, how the CanvasReneringContext is defined in the IDL and cpp file etc. Could someone give me some pointers where the actual printing of a canvas element to the printing context happens, such that I could try to implement the proposed callback?

Best,

Julian

After thinking about the proposed ideas in Robert's first reply, based on the feedback to my raised questions (you guys are awesome, thanks!) and talking to some other people, I think it's best to drop the WebPrintAPI proposal and go with what Robert proposed.

That requires two things to get implemented in Gecko:

i) Implement a subset of CSS3PagedMedia to set the margin (at least the case = 0 to hide all the header/footer) and the page size.
ii) Implement a new callback on the canvas element that is called during the actual printing to print directly to the printing backend.

What's the best way to get the implementation going?

For i), there seems to be a bug already: https://bugzilla.mozilla.org/show_bug.cgi?id=115199

I tried to understand what the patches are doing and couldn't figure it out for most parts. For i), is the way to implement this by continue working on bug 115199, or should there be a new bug that tries to implement only a very dump subset of the CSS3PagedMedia, such that one can set the margin to 0 and the page-size and that's it?

From my intuition, the second part ii) might be "easier" to implement then the first part, as it is more contained and doesn't require to deal with new CSS rules. I'm therefore wondering if you think this is something I could try to implement.

So far I have some basic understanding about how the printing stuff works, how the CanvasReneringContext is defined in the IDL and cpp file etc. Could someone give me some pointers where the actual printing of a canvas element to the printing context happens, such that I could try to implement the proposed callback?

Best,

Julian

I think starting with the patch there is the way to go. You'll need to add
code to nsSimplePageSequenceFrame::Reflow to set up margins using the style
data from a (the first) nsPageFrame child.

Basically we just render the canvas like normal, but we're rendering it to
a print context.

What I think you need to do is:
-- in nsHTMLCanvasElement::CopyInnerTo in the IsStaticDocument case, set up
a reference from the cloned-for-print canvas to the original canvas
-- in nsSimplePageSequenceFrame::PrintNextPage, before you render the page
via nsLayoutUtils::PaintFrame, traverse the child page frame's frame
subtree (see FrameChildListIterator and its users) looking for
nsHTMLCanvasFrames (via do_QueryFrame). For each one, look up the original
canvas, see if it has an "onprint" (or whatever we call it) event handler
set on it. For those that do:
  -- Poke the printed nsHTMLCanvasElement's 2D rendering context
(nsCanvasRenderingContext2D for now) to tell it to change its surface to a
new surface created via
renderingContext->GetThebes()->CurrentSurface()->CreateSimilarSurface()
  -- Synchronously dispatch the "print" event to the original canvas.
  -- That event should use a custom DOM event class (see for example
nsDOMNotifyPaintEvent) with an extra field that's the 2D rendering context
for the printed nsHTMLCanvasElement
  -- To save memory, after calling PaintFrame for the page, go back through
the canvases where you fired the callbacks and clear out their surfaces.

If you're really lucky, that will be enough for printing :-). For print
preview:
-- Add an mIsReadyToPrint flag on nsHTMLCanvasElement, initially false,
-- Add an IsReadyToPrint() method on nsPageFrame that scans the frame
subtree (see FrameChildListIterator) looking for nsHTMLCanvasFrames (via
do_QueryFrame). If any such canvases have their mIsReadyToPrint flag not
set, and the original canvas has an "onprint" callback, the page is not
ready to print.
-- When painting an nsPageFrame in print preview, if !IsReadyToPrint(), for
each not-ready print canvas, clear out its surface and fire an asynchronous
event that dispatches a "print" event to the original canvas, passing the
2D rendering context for the print canvas's context, and when that event
has finished set the mIsReadyToPrint flag on the print canvas.
-- To save memory, periodically check for pages that are offscreen and
clear out the surfaces for the print canvases in them.

At some point, hopefully soon, nsCanvasRenderingContext2D will go away and
you'll need to make these changes to nsCanvasRenderingContext2DAzure
instead.

Rob
--
“You have heard that it was said, ‘Love your neighbor and hate your enemy.’
But I tell you, love your enemies and pray for those who persecute you,
that you may be children of your Father in heaven. ... If you love those
who love you, what reward will you get? Are not even the tax collectors
doing that? And if you greet only your own people, what are you doing more
than others?" [Matthew 5:43-47]

On 03/14/2012 05:24 PM, Zack Weinberg wrote:

On that topic, I would suggest some close reading of the absolute units
section here:
   http://www.w3.org/TR/CSS21/syndata.html#length-units

~fantasai

On 03/14/2012 05:56 PM, Jet Villegas wrote:

That depends on what's in our UA and user style sheet levels. Presumably
the default for web pages will include the title/URL/timestamp/etc. like
we do today.

I would strongly recommend referring to the editor's draft for now.
   http://dev.w3.org/csswg/css3-page/
For various reasons (that have little to do with W3C and more to
do with the printer industry and me being switched to other tasks
like CSS2.1), the draft you link to is very out-of-date...

We've also gotten some significant comments on the margin box sizing
rules from Simon Sapin on www-style; if you're going to implement
margin boxes, you'll want to track those discussions.

   http://lists.w3.org/Archives/Public/www-style/

The CSS3 Paged Media discussions on www-style are tagged with [css3-page].
Feel free to poke me with any questions; I'm the spec editor. And please
send comments about things that are stupid or broken to www-style so we
can fix them...

~fantasai

Rob, thanks a lot for your step points on how to get this implemented - this is way more detailed then I've expected it to be :)

If we use events here, there could be two callbacks listening for the same event. To keep it easy, I propose to define a new `printCallback` attribute on the nsHTMLCanvasElement, that takes a JSFunction as argument.

Are there advantages in using an event instead of a simple callback that I don't realize?

With the idea of the `printCallback` from above, the first argument would be the new created RenderingContext.

Rob, thanks a lot for your step points on how to get this implemented - this is way more detailed then I've expected it to be :)

If we use events here, there could be two callbacks listening for the same event. To keep it easy, I propose to define a new `printCallback` attribute on the nsHTMLCanvasElement, that takes a JSFunction as argument.

Are there advantages in using an event instead of a simple callback that I don't realize?

With the idea of the `printCallback` from above, the first argument would be the new created RenderingContext.