[cairo] Size of PDF when splitting a PDF surface
M Joonas Pihlaja
jpihlaja at cc.helsinki.fi
Wed Aug 18 04:42:00 PDT 2010
On Wed, 18 Aug 2010, Thomas Petazzoni wrote:
> In the new version of MapOSMatic we're developing, we are implementing
> a "booklet" rendering mode: instead of having the city map rendered on
> a single, large PDF file that is hard to print on common printers, we
> will split the map on different (A5, A4, etc.) pages.
> To do this, we ask Mapnik to render the full map in a single large
> Cairo PDFSurface, and then create another Cairo PDFSurface of the
> destination size
> to render on each page a part of the original Cairo PDFSurface.
You can do that, but it's much better if you restrict the geometry
sent to cairo at the application level. Separating the geometry
fetched for the extents of interest from the actual rendering will
also let you scale to much larger maps.
> Is our way of extracting parts of a surface into another surface
> incorrect ?
It's not incorrect, just inefficient. The key here is IMHO to think
of clipping and culling in your app where it can be done much more
efficiently than within cairo. In fact, for the kind of rendering
you're doing, I suggest you treat cairo as a limited precision output
device capable of rendering only small geometries to a small area of
> Is there a way of making sure that Cairo includes only once in the
> final PDF the contents of the original surface ?
Cairo could create a group for your entire map I suppose and then
merely convert your fill operations to something that refs the group.
Printers would likely try to render each primitive for every page,
however, so with larger booklets printing may become intolerably slow
More information about the cairo