[cairo] Re: Embeding JPG in PDF

[Kristian Høgsberg]

On 1/9/07, Emmanuel Pacaud <emmanuel.pacaud at lapp.in2p3.fr> wrote:
> On mar, 2007-01-09 at 04:57 +0000, Alp Toker wrote:
> > Kristian Høgsberg wrote:
> > > On 1/8/07, Behdad Esfahbod <behdad at behdad.org> wrote:
> > >> Hi,
> > >>
> > >> So, there's this bug against eog (GNOME image viewer) [1] about images
> > >> printed to PDF are huge.  The reason of course is that cairo embeds
> > >> images as PNG.  We need to find a solution to this.
> > > ...
> > >> My personal preference is to add just enough API to cairo-pdf.h that a
> > >> toolkit like pdftk can /integrate/ with cairo, to produce more advanced
> > >> PDF documents.  That's what we do for text: delegate to pangocairo.
> > >
> > > My thoughts about this is that we could add a function like
> > >
> > > cairo_surface_t
> > > cairo_pdf_surface_create_from_jpeg(const char *filename);
>
> I don't think it's a good idea. It would be a very specific solution to
> a very specific problem, and a call to a lot more similar specific API
> calls. And JPEG embedding is also something we want for the SVG backend.
>
> > Maybe there's an opportunity here to integrate some of the lossless
> > jpeg rotation, cropping and joining algorithms like
> > http://sylvana.net/jpegcrop/jpegtran/ in the form of a jpeg surface that
> > can both read from and write to jpeg files?
>
> That would be better, and even better without a specific surface. A
> cairo_image_surface_create_from_jpeg () would load a jpeg image in
> memory and keep it as jpeg data, with some internal cairo API that would
> allow other backend to get directly these raw data. Only an
> acquire_image would trigger jpeg decompression.

That was basically what I was trying to describe, maybe I was wrong to
suggest that it should return a pdf surface.  But yes, provide a
function to create some kind of cairo surface from jpeg data, let
backends that can use the jpeg data get to it, and decode the jpeg on
demand in acquire_image.

Kristian