[cairo] Embedding jpeg in pdf

[Michael Sløgedal]

How about this?

If there's no plans of implementing image format support in cairo, at the
very least there should be backing functions with callbacks as mentioned
before.

cairo_image_surface_compressed_data_set(char *data, int len); -- to set the
compressed attachment
cairo_image_surface_compressed_data_get(); -- to retrieve the pointer to the
compressed data (in case it has been recompressed using callbacks)
cairo_image_surface_compressed_data_uncompress(callback(char *data,int
len)); -- to request user application to uncompress the compressed data to a
regular image buffer
cairo_image_surface_compressed_data_compress(callback(cairo_surface_t *));
-- to request user application to recompress data to the compressed
attachment

cairo would be the one requesting an uncompress/recompress when necessary
(drawing on surface, painting surface, saving surface)

some #defines for each type of image format and a way for cairo to
internally know which formats are supported by which surfaces, I would
recommend - but that could be up to user application to know, I suppose.

Michael S


-----Original Message-----
From: cairo-bounces at cairographics.org
[mailto:cairo-bounces at cairographics.org] On Behalf Of Vladimir Vukicevic
Sent: 14. juli 2008 23:15
To: Bill Spitzak
Cc: cairo at cairographics.org
Subject: Re: [cairo] Embedding jpeg in pdf


On Jul 14, 2008, at 1:25 PM, Bill Spitzak wrote:

> Based on my experiences with the mess that was inserted into fltk, I
> think the following is the right solution, that both gets an api that
> end users really want, and also avoids jpg dependencies.
>
> There would be a new type of surface, replacing the png one, and
> designed to hold an *arbitrary* file or stream of data. By default  
> Cairo
> would only understand .png files (and probably a compilation switch to
> make it understand *no* files), and some source code would be provided
> to show how to add libjpeg as a new interpreter. This surface would  
> keep
> track of the stream data and also a pointer to an interpreter object
> that decodes it into pixels.

Why?  The interesting piece of functionality is being able to embed  
jpeg data into cairo's PDF and PS output.  Everything else, I think,  
is unnecessary.  We just need to attach a chunk of data that cairo has  
a little bit of knowledge about to a surface ("This is JPEG data; it  
is not a progressive jpeg"), and have a few places in the code that  
can check for that data.

Decoding any kind of image data really shouldn't be part of cairo's  
core API, just like doing real text layout isn't, how handling  
truetype files isn't, and how interpreting SVG isn't.  The pieces that  
are in there -- PNG decoding and the toy text API -- are there purely  
for test support, and I now really wish that they were cairo_test_*  
that are only compiled in if you explicitly enable testing  
infrastructure.  Apps really shouldn't be depending on using cairo for  
PNG decoding or for text layout, and I don't think we should be  
extending functionality further in similar directions.

     - Vlad

_______________________________________________
cairo mailing list
cairo at cairographics.org
http://lists.cairographics.org/mailman/listinfo/cairo