> 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
The points above seem to work in a very hacked up first version :)
Instead of the event I use callback style for now. The first argument gets the
rendering context and the second argument is an object, that contains
additional data.
You can find my current "test" file here:
https://gist.github.com/2230187
This is what the print output looks like (used "Save as PDF" option):
http://n.ethz.ch/~jviereck/drop/Preview_print_test.pdf
There are some questions now arising:
-- What should be the unit system for the context used in the mozPrintCallback?
Right now, one unit corresponds to the length that one pixel of the canvas gets
mapped to in the actual printout. That has nothing to do with the 1/72 inch or
1/92 inch mentioned in this thread. However, the way it's right now is what
people might expect. If they write a rendering function like I did in the gist
file, then they just can reuse it during rendering as well and don't have to
adjust the unit system depending on printing to screen or printer.
-- Is there a way to figure out the DPI resolution of the printout in C++?
-- ctx.getImageData and ctx.putImageData work as expected. The second rectangle
you see in the example PDF on the bottom right was created using getImageData
and putImageData. During this process, the vector information gets rastered and
therefore the text quality of the second rectangle is poor compared to the
original one. The resolution stays the same during the rastering process as it
would in the "normal" DOM case. For the printing case, it might be useful to
request imageData with a higher resolution. Should there be a new parameter for
the getImageData and putImageData to specify the resolution? E.g
getImageData(x, y, width, height, 100) returns imageData where each "normal"
pixel corresponds to 100 pixel.
-- How can one figure out the actual size of the canvas when printed to paper?
I guess I can get some size-information from the CanvasFrame, but is that the
actual/resulting size on paper?
>> In addition, there need to be a way to scratch an element onto an entire
>> print page. E.g. a canvas should take up the entire page if the margin is
>> set to zero. Can that be done using something similar to
>> style="width:100%;height:100%"?
>
> Yes.
Rob, what was your idea to use for this?
_______________________________________________
dev-tech-layout mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-layout
