[cairo] Output of physical resolution of bitmap images

Henner Zeller h.zeller at acm.org
Sat Feb 18 05:37:53 UTC 2017


Bitmap formats often have a header field that translates the
dimensionless pixels into real world sizes. An image that is 1000x1000
pixels large does not give any hint how large it should be printed on
paper. If the image header has an information, saying 'this is meant
to be 500dpi', then it is clear that this is a 2"x2" image.

If you open such an image with gimp for instance, and look at image
properties, it will give the correct physical size alongside the
pixels. If no such dpi (or ppi) information is given in the image meta
data, it will just assume 1/72" (=point), but that is not typically
correct if you explicitly create a high-resolution image of something
to be printed in a particular size (I am trying to do this with PCB
artworks to communicate with a lithography device I am building).

(This is not something needed in vector formats, as they already
represent physical sizes, such as 'point' (1/72) in PostScript or

Anyway - it looks like there is no way to set the resolution on a
cairo_surface_t which then would be written out in a png-header when
calling cairo_surface_write_to_png().

Cairo never sets the resolution when writing the PNG (which would be a
call to png_set_pHYs()).

This is a real limitation, because it means you can't create a
high-resolution image of something and have the receiver of the image
know exactly the size of the artwork.

Looking at the API, there is only one resolution specific value to be
set on cairo_surface_t: the 'fallback resolution', but it is only
meant as a hint for resolution of raster output to be embedded in a
vector file; it is entirely unused for PNG.

In the attached patch, I have used this value to set the physical
resolution of the output image. While this works, it is somewhat
conflating the original meaning of the
So ideally I would probably slightly prefer to have a dedicated
cairo_surface_{set,get}_resolution(), but it might change the API too
much. Maybe it is simpler to adapt the documentation of the fallback
description. Your call :)

So see attached patch (against current git) more a suggestion; Note,
this is also needed in other image formats - AFAIK the JPEG image
format also has an optional header that describes the physical

-------------- next part --------------
A non-text attachment was scrubbed...
Name: png-resolution.patch.gz
Type: application/x-gzip
Size: 456 bytes
Desc: not available
URL: <https://lists.cairographics.org/archives/cairo/attachments/20170217/68282ca0/attachment.bin>

More information about the cairo mailing list