PNG files written with wrong resolution in header

[mhirsch]

Currently, a PNG encoded by node-canvas doesn't contain the correct physical size information in the header. In canvas_write_png() in PNG.h you never call png_set_pHYs() to set the physical units in the PNG header, so it defaults to 72 PPI. Most screens are 96 PPI.

Generally it would be awesome to have a way to set the physical size of the canvas from javascript. I personally would like to use this for print, where the DPI in the header changes the way the document is printed. Right now I am running an imagemagick command after the PNG is written to a file, but this is inefficient.

I could offer a patch, but of course it would be another non-standard function. I'd like to hear the thoughts of the project leaders on whether this would be something of general interest or not before I write anything.

This is potentially related to Issue #716, in that scaling the canvas may indicate that the user is looking to produce a PNG for higher PPI screens, and the PNG/SVG/PDF should probably reflect the true physical dimensions of the display device.

[LinusU]

Hmm, very interesting indeed.

Have you tried exporting PNGs from different web browser and see what they set as the PPI?

[mhirsch]

It seems browsers also always set the PPI to 72. There's no mechanism in the canvas spec to set the physical dimensions, so I suppose that makes sense. I don't think node-canvas should boil the ocean in making things too non-standard, which is why I'm asking for people's opinion here. It's just that I'd find it personally convenient to have such a feature! :P

[zbjornson]

The spec says if the file format used supports encoding resolution metadata, the resolution must be given as 96dpi (one image pixel per CSS pixel), so I think this is indeed a bug. https://html.spec.whatwg.org/multipage/canvas.html#a-serialisation-of-the-bitmap-as-a-file

In #1152/#982 I'm proposing a config object for toBuffer, so if we want to make this configurable, it would be easy to add a resolution parameter there. That would fix #716 too.