(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.)
>> 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. > > For the PDF.JS one could code around the missing page orientation feature by > rotating the content in the canvas used for printing. > > 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. > > >> -- 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). > > The output should get passed to the printing backend conserving the vector > information. That way, if the user selects "Save as PDF", s/he can still > select text and scale the PDF to higher resolutions. Also, the printout will > look better if the data is kept in a vector format. > > Right, so what you would do is pass a special 2D context object with the > event, where the methods on that context object generate PDF directly. This > wouldn't be terribly hard to implement and it would be really easy to use for > Web developers since they could use their existing "paint the canvas" code. > This context object should support the full canvas API (although > getImageData/putImageData need not produce great results). > > The rendering event handler may need to generate temporary canvases that are > good for printing, so maybe we'd need to provide a way to do that. > > Assume the "drawForPrinting" callback is called and the page renders to a > special context object. It's not unusual that rendering a single page can > take several seconds (very graphic intense PDFs…). Therefore, there should be > a way to continue the printing after a setTimeout(). The setTimout is > necessary to let the browser become responsive. For the WebPrintAPI I > proposed to add a new `endPage()` function on the print rendering context. > Would "pausing the rendering" be possible here as well? > > Hmm. Not sure. 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? > While calling the canvas rendering function, this function might have some > side effect that removes an element from the document, such that the print > layout changes. Is the layout required to update then? What should happen if > a canvas gets removed from the document that was not rendered yet? > > We can specify that printing works on a snapshot of the document (with the > events fired at the corresponding canvases in the real document) so that > isn't an issue. That is in fact how Gecko works. > > The idea described here seems to enable most of what is described in the > WebPrintAPI proposal. The WebPrintAPI proposal is superior to the idea > described here as it doesn't require to build up some "fake" canvas that are > only used for printing and makes it easier to implement page preview. Also, > the maximum number of pages is determined using a JS function, while this > HTML/CSS idea requires canvas for all print pages to be added to the DOM > before the actual print out which might get very memory intense for large > documents (> 1000 pages). > > I guess one question is, is it possible to do effective print preview of > documents with > 1000 pages without using too much memory --- with any > solution? If not, what goals should we be aiming for? I'm sorry - I don't understand what you mean by "--- with any solution"? Julian _______________________________________________ dev-tech-layout mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-layout
