- From: Robert O'Callahan <robert@ocallahan.org>
- Date: Tue, 29 Jan 2013 23:18:57 +1300
- To: Elliott Sprehn <esprehn@gmail.com>
- Cc: whatwg <whatwg@lists.whatwg.org>, Julian Viereck <julian.viereck@googlemail.com>
On Tue, Jan 29, 2013 at 7:33 PM, Elliott Sprehn <esprehn@gmail.com> wrote: > Why can't I do this for <video> or <object> or any number of other things > then? All those things want to be beautiful when printed too. :) In that > world I really think we want something closer to Element#printCallback. > That doesn't make sense to me. <canvas> is special because we have APIs to draw into it, and authors can use the same code that draws a screen canvas to draw a beautiful print canvas with very few changes. The contents of <video> and <object> aren't rendered by author JS code, so it's not natural to provide an API that lets them be rendered by author JS code just for the print case. However it is possible with our proposal for authors to use some clever @media CSS to replace any element with a pretty <canvas> version if they need to. Also, <video> and <object> (and <img>) have features that could be used to have them print nicely without author script having to take over their drawing. For example, on some platforms a plugin in an <object> can define custom printing behavior. Vector graphics is exactly what you want when the data model is really big > though since it lets you prune out things you know can't be seen and stream > the commands directly to hardware without rasterization as they're > attempting to do with <canvas> magic in this proposal > I'm not sure what you mean here. In our prototype implementation in Firefox, when drawing in a printCallback and printing to a PDF, if the author's canvas drawing calls can be directly supported by PDF then they are emitted into the PDF and not rasterized at all. If SVG is broken for this use case we should fix that, it seems really sad > to "give up" on SVG and bolt vector graphics onto <canvas>. > If you have a very large data model to render, converting directly from the data model to (GL or 2D) drawing commands is a lot more efficient than building a persistent CSS-styled DOM as an intermediate step. Having the browser optimize away that intermediate step doesn't seem feasible. Rob -- Jesus called them together and said, “You know that the rulers of the Gentiles lord it over them, and their high officials exercise authority over them. Not so with you. Instead, whoever wants to become great among you must be your servant, and whoever wants to be first must be your slave — just as the Son of Man did not come to be served, but to serve, and to give his life as a ransom for many.” [Matthew 20:25-28]
Received on Tuesday, 29 January 2013 10:19:42 UTC