[cairo] Embedding jpeg in pdf

[Vladimir Vukicevic]

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