[cairo] Patch for cairo - high resolution images in PDF surface.

Andrew McRae amcrae at employees.org
Sun Nov 26 17:52:20 PST 2006


On Sun, 2006-11-26 at 20:37 -0500, Behdad Esfahbod wrote:
> On Sat, 2006-11-25 at 22:24 -0500, Andrew McRae wrote:
> > Comrades,
> > Attached is a patch generated against the git mainline - I wasn't
> > entirely sure if the right thing to do was to send it here or somewhere
> > else. At least I'll learn the right way to do it for next time! :-)
> > 
> > This patch allows higher resolution images to be embedded in
> > PDF surfaces - the idea is that you can set the fallback resolution
> > on the image, and the PDF surface can use this as a hint for the
> > DPI of the image. One part of the change is to have a flag to
> > remember when the fallback resolution is actually set (as opposed
> > to just having default values).
> > 
> >     surface = cairo_pdf_surface_create("test.pdf",
> >                         8 * 72.0, 10 * 72.0);
> >     img = cairo_image_surface_create_from_png("large.png");
> >     cr = cairo_create (surface);
> >     // Use 300 DPI for image.
> >     cairo_surface_set_fallback_resolution(img, 300.0, 300.0);
> >     // Use 1/2 inch margin.
> >     cairo_set_source_surface(cr, img, 36.0, 36.0);
> >     cairo_paint(cr);
> >     cairo_show_page(cr);
> > 
> > Feedback welcome...
> > Cheers,
> > Andrew McRae
> 
> So, if I understand your patch correctly, you are making it to use the
> image resolution instead of assuming a 1:1 mapping between image and PDF
> device units.  That may be useful, but only if implemented on ALL
> operations, not only painting an image into a PDF.  On the other hand,
> it complicates cairo's simple model without much, if any, advantage.

The main advantage is that most existing operations on a PDF
surface are well supported as vector operations without
resorting to lower resolution images e.g lines, fonts,
arcs etc. Where this falls down are bit-mapped images, which
by default appear as 72 DPI images - the consideration is that
this is one of the commonest operations, and so is useful in
a large number of cases. Which other operations do you think
it should be supported on?
In some ways it doesn't really do anything to the cairo model
itself, but to the PDF backend. I agree that it could be
seen as a kludge, and am happy to hear suggestions as to how
we could do this with alternative approachs (that is the
underlying point of the email, really :-)
The thing is that the client code has exposure
already to the fact it is a PDF surface, so it
didn't seem too much of a twist to do it this way.

I think the wider issue is that it does highlight the fundamental
difference between bitmapped and vector backends, and how much
should cairo be concerned with hiding the details of each (at
whatever cost that is).
Cheers,
AMc



More information about the cairo mailing list