Re: [whatwg] Proposal: HTMLCanvasElement.printCallback API

On Mon, Jan 28, 2013 at 6:02 PM, Robert O'Callahan <robert@ocallahan.org>wrote:

> On Mon, Jan 28, 2013 at 6:25 PM, Elliott Sprehn <esprehn@gmail.com> wrote:
>
>> 3) If we're advocating that developers "put a canvas on every page that
>> covers the whole page" as the standard way to handle large document
>> printing why not have a handler that gets given a canvas for every page
>> automatically instead of requiring the developer to insert it themselves.
>>
>
> Another use-case is when you have a document that's regular HTML and just
> happens to contain one or more <canvas> images that should be beautiful
> when printed.
>

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.


> 4) SVG is for vector graphics, not canvas. Why can't I replace an entire
>> page with an <svg> instead of drawing to a canvas? :)
>>
>
> SVG doesn't fit some use-cases very well, for example, when you generate
> graphics from some underlying (large) data model.
>

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.

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>.

- E

Received on Tuesday, 29 January 2013 06:34:17 UTC