[cairo] Size of PDF when splitting a PDF surface

[M Joonas Pihlaja]

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.

Wonderful.

> 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 
interest.

> 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 
or impossible.

Joonas