[cairo] JPEG support patch

[Bill Spitzak]

Actually DevIL is the library I was thinking of when I was trying to 
make a proposal for a new cairo pattern t.

Perhaps Cairo can just require DevIL. Several other libraries do such as 
Ogre (which is where I discovered it) so this may not be too much of a 
problem. For the pdf output that originally initiated this discussion, 
it would still be a good idea to add a new cairo_pattern_t that wraps 
DevIL. The reason for this is so it can be set as a source in the pdf 
backend, and the pdf backend can recognize it is a DevIL image, get at 
the DevIL data and figure out it is a jpeg, and from there extract the 
compressed jpeg data directly.

DevIL also has the ability to directly produce an OpenGL texture, which 
might be useful for the Glitz backend when it recognizes source patterns.

It might be a good idea to leave "DevIL" out of the api so that image 
file back end could be changed to a different library. However I expect 
the pdf backend may have to assumme DevIL to get the format-specific data.

Something like:

cairo_image_pattern_create("filename");
cairo_image_pattern_create(const char* data, int length); // mmap
cairo_image_pattern_create(readf, seekf, closef); // io callbacks
cairo_image_pattern_DevIL_id(image_pattern_t) // returns the DevIL id or 
whatever.

Andrew McRae wrote:

>> There are already a pile of pretty good image loading libraries (DevIL 
>> comes to mind) that will happily load into a cairo_image_surface_t -- if 
>> you think there's a need for yet another image loading library that's 
>> specifically tied to cairo, I'd say go for it, but please keep it out of 
>> cairo proper.