Bug 9052 - <canvas> content prints at screen resolution instead of printer resolution
Summary: <canvas> content prints at screen resolution instead of printer resolution
Status: RESOLVED WONTFIX
Alias: None
Product: WebKit
Classification: Unclassified
Component: Layout and Rendering (show other bugs)
Version: 420+
Hardware: Mac OS X 10.4
: P3 Normal
Assignee: Nobody
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2006-05-22 17:57 PDT by Eric Seidel (no email)
Modified: 2008-06-30 09:39 PDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Eric Seidel (no email) 2006-05-22 17:57:57 PDT
<canvas> content prints at screen resolution instead of printer resolution

We should use some sort of PDFContext instead of the current BitmapContext for the <canvas> backend, to allow canvas content to print nicely.

We have a Radar for this already, I don't remember the number (and don't have radar on this machine).  I believe it was filed by Martin Ott.
Comment 1 Andrew Pouliot 2007-10-29 12:27:06 PDT
I think this is not possible due to the philosophy of <canvas> as a bitmap graphics context (with vector input). Authors of <canvas> pages are relying on the fact that certain operations take a small amout of time when done with limited numbers of pixels, and the fact that when overwritten, pixels "go away" meaning require no further storage.

However, if every drawing operation performed on the canvas is cached and then replayed for printing, there could be a ton of drawing commands that essentially make some pages non-printable because it would take forever to compute what actually needed to be drawn for printing.
Comment 2 Oliver Hunt 2008-06-27 21:24:37 PDT
This doesn't make sense in the context of the canvas element (especially given it now includes actual raw bitmap access).
Comment 3 Alexey Proskuryakov 2008-06-28 01:30:09 PDT
<rdar://problem/4364207>
Comment 4 Eric Seidel (no email) 2008-06-30 09:39:41 PDT
Well, it would still be possible to support both. :)  But it's also fine to close this.  We have many many many more things to fix with printing first. :)