W3C home > Mailing lists > Public > whatwg@whatwg.org > January 2013

Re: [whatwg] Proposal: HTMLCanvasElement.printCallback API

From: Robert O'Callahan <robert@ocallahan.org>
Date: Tue, 29 Jan 2013 23:18:57 +1300
Message-ID: <CAOp6jLbSZ7zQqBkCO8+DPrPCgMcH8u1ohOaejBPj1xpr2x1jtw@mail.gmail.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 30 January 2013 18:48:12 GMT