[cairo] Embedding jpeg in pdf

[Jeff Muizelaar]

On Mon, Jul 14, 2008 at 02:23:30PM +0000, Benjamin Otte wrote:
> Vladimir Vukicevic <vladimir <at> pobox.com> writes:
> 
> > > The second patch implements PDF embedding of jpeg images. The third
> > > patch adds the API function:
> > >
> > > cairo_surface_t *
> > > cairo_image_surface_create_from_jpeg (const char   *filename)
> > 
> > I dislike this part -- the png stuff is in cairo because of testing,  
> > but I don't think we need to do jpeg decoding in cairo and especially  
> > don't need to add a dependency on libjpeg.  If an application wants to  
> > embed jpeg images, it's probably already decoding jpeg images for its  
> > own purpose -- there's no reason for cairo to duplicate that  
> > functionality.  (For testing purposes, it's probably ok to add a  
> > dependancy on libjpeg for the test itself, though.)
> > 
> I would have said this API is the only sane way to support any image format. But
> this is likely because Swfdec as a library tries to live without its own image
> handling library.
> Anyway, there's some problems I have with not depending on libjpeg:
> 1) I think most backends that support JPEG only support a subset. I guess you'd
> need libjpeg to figure out if the current JPEG data is supported anyway. (The
> same would likely be true for other image formats, too.)

This is a interesting issue. The only difference I know about in level
of support is progressive JPEGs. They are not supported by postscript
but are supported by PDF 1.3+. I don't think it would be too hard to
determine whether a jpeg is progressive or not without depending on
libjpeg. I also assume GDI does not support progressive JPEG but I
haven't been able to find any information confirming that.

As for confirming that the JPEG data is actually valid I think it makes
sense to punt that to the application. Applications will already need to
do this anyways.

> 2) rendering to a surface with attached JPEG data would invalidate
> this data.> Should the surface be reencoded to JPEG when writing to a
> PDF or should it be
> written as raw image data?

I'd say raw image data. Writing to a surface with attached JPEG data 
doesn't really make sense and ideally this would be forced by the API
somehow. 

If the data was reencoded, cairo would probably need some sort of idea
about the quality parameters to reencode the image.  While it appears
that it is possible to estimate the quality level
http://www.impulseadventure.com/photo/jpeg-snoop.html. However, the
whole quality decision seems like it should be up to the application
instead of cairo.

> 3) Cairo not providing the ability to decompress JPEG files confuses many
> newcomers to the Cairo API. How to render JPEG and SVG files are two of the most
> common questions in #cairo. JPEG not being available is extra confusing because
> decoding works for PNG files.

I think it would be good to have an additional cairo utils library that
would do this kind of thing along with other tasks that are supported on
top of the existing api. It could also include things like rounded
rectangles, blur filtering etc.

-Jeff