[cairo] JPEG support patch

[Behdad Esfahbod]

On Fri, 2007-01-19 at 14:30 -0500, Vladimir Vukicevic wrote:
> 
> Hmm.. there already is a surface_pattern, and surfaces can have 
> arbitrary data attached to them.  It seems like the pdf backend can
> just 
> check for some well-known compressed_data_key data to be set on the 
> surface, that would be a struct that looks like:
> 
> struct compressed_image_data {
>    char *type; // "image/jpeg"
>    unsigned long data_length;
>    unsigned char *data;
> };

I was kinda thinking along the same line to allow the user to set a
mapping of mime types to data on the pattern.

However, the current user_data mechanism cannot be used for this purpose
as it needs the key to be shared by all users.  This at least needs some
new API.

Like the idea, but I prefer some more /natural/ kind of API.  Lets  see:

  - Where do we want to add it:  on the surface or on the pattern?
pattern makes sense, since you may want to use the JPG data in one
operation and not in another one.  Surface makes sense because that's
where the data is coming from.  So, maybe have the option to set on
both, and the patterns falls back on the surface if none set on it.

  - Is it important to be able to not require decoding the image at all?
In that case a new kind of surface or pattern is needed.  One that an
image surface can be obtained from and JPG/TIFF/... data can be obtained
from.  If we don't care about forcing the user to decode the image
anyway, it may as well be any surface.  Or a surface pattern.

And a callback API is probably preferred.  A cairo_read_t+closure should
do it.  And to go with the rest of the API, a filename version too.
Something like:

  cairo_surface_set_data_getter_for ("image/jpeg", my_jpg_getter);

Now that's a crazy name I agree.  As closure we pass in the surface.
The user can use the user_data on the surface to pass in arbitrary data.
Same for pattern.  Plus getters for them?  The surface backend then can
go over all the data getters set on the pattern, go over them in some
order (what the user set, or what it prefers), and pick the first that
returns SUCCESS...

Anyhow, just dumping my ideas.

behdad

> (or whatever -- maybe a getter function so that the data doesn't have
> to 
> stay in memory, etc.)
> 
> If it finds one of those and recognizes the type, it can embed the
> image 
> data directly.  I don't understand why doing this would require
> adding 
> any API to cairo itself (other than the image data struct/global key)
> -- 
> certainly there could be helper libraries that would simplify the
> image 
> loading process, but other than that, it would just be a few changes
> to 
> the PDF backend using already existing infrastructure...
> 
>      - Vlad 
-- 
behdad
http://behdad.org/

"Those who would give up Essential Liberty to purchase a little
 Temporary Safety, deserve neither Liberty nor Safety."
        -- Benjamin Franklin, 1759