[cairo] Embedding jpeg in pdf
vladimir at pobox.com
Mon Jul 14 14:15:05 PDT 2008
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
> 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
> 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.
More information about the cairo