Bug 9052
| Summary: | <canvas> content prints at screen resolution instead of printer resolution | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Eric Seidel (no email) <eric> |
| Component: | Layout and Rendering | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED WONTFIX | ||
| Severity: | Normal | CC: | andpoul, ian |
| Priority: | P3 | Keywords: | InRadar |
| Version: | 420+ | ||
| Hardware: | Mac | ||
| OS: | OS X 10.4 | ||
Eric Seidel (no email)
<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.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Andrew Pouliot
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.
Oliver Hunt
This doesn't make sense in the context of the canvas element (especially given it now includes actual raw bitmap access).
Alexey Proskuryakov
<rdar://problem/4364207>
Eric Seidel (no email)
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. :)