While thinking about what a proposal to WHATWG about the printCallback-API
should look like, I've came across the following edgecases.
* the context passed to the mozPrintCallback function has a `canvas` property.
I think this `canvas` property should not exist on the mozPrintCallback passed
in `ctx` and should return `undefined.
What should this canvas be? If it's the canvas of the print-document,
performing operations like `appendChild` to the HTML tree, that gets printed,
can cause issues, as it's assumed that this tree is static and can't change. On
the other side, the `canvas` might refer to the canvas in the DOM, but this
canvas was removed in the meantime (= during the time frame the printing starts
and the callback is called) maybe .
Instead, I propose the second argument passed to the callback should contain
the `width`, `height`, `id` and `name` of the canvas as at the beginning of the
printing process.
The usage of the mozPrintCallback might then look like this:
canvas.mozPrintCallback = function(ctx, obj) {
console.log(obj.width, obj.height, obj.id, obj.name);
// ...
}
* The current implementation sets the size of the rendering context to the size
of the actual canvas on the screen if in preview. The canvas context is then
scaled, such that the behavior of the canvas context "feels" the same in normal
DOM usage. While this works, this might cause problems when using
`getImageData` on the canvas.
Imagine the print preview has a zoom set to 10%. If the canvas has normally a
width of 100px, it might now only have 10px in preview. The internal used
context of the canvas is then only 10px in width, but if the user requests
imageData with width 50px, this gets mapped down to 5px (due to internal
scaling). But then the 5px gets scaled by factor 10 to get the 50px of the
imageData size. As a result, the imageData the user gets might not be of the
quality it is used to be.
To solve this, should the canvas context size be at least the size of the
canvas.width/canvas.height as specified in the DOM? If the size is larger,
there might still be some loose in quality, as the data needs to be down-scaled
for the requested imageData (imagine the canvas has a width of 100px in the DOM
and 200px in preview - then the canvas context has a width of 200px as well and
the width is scaled by a factor of 2 when a getImageData requiest is done). But
I don't expect the image quality loose too be as bad as when the canvas context
gets very tight compared to the expected canvas size.
Does these changes make sense?
Best,
Julian
_______________________________________________
dev-tech-layout mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-layout
