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
dev-tech-layout@list...
https://lists.mozilla.org/listinfo/dev-tech-layout