[cairo] Re: Embeding JPG in PDF

[Jeremy Lea]

Hi,

On Fri, Jan 12, 2007 at 02:50:13AM -0500, Behdad Esfahbod wrote:
> On Wed, 2007-01-10 at 08:36 -0500, Kristian Høgsberg wrote:
> > 
> > The topic isn't about encoding images lossyly to jpeg, it's about
> > images that are already stored as jpeg and can be directly embedded in
> > the pdf as such.  It's a valid use case, but it's not clear how the
> > API should look. 
> 
> This was the topic that started the thread.  But since, I've convinced
> myself that we need to allow embedding an image surface into PDF in JPG
> instead of PNG too, for sole size purposes.

While reading some mozilla bugs looking for a problem I was having, I
can across a discussion on trying to save X server pixmap space
(259672).  In it Robert O'Callahan had made some comments about sending
compressed images to the X server, and letting it do the decoding...  I
made a comment, which I think also applies to this situation.

What cairo needs is a image helper library.  There are lots of these out
there, so one wouldn't have to start from scratch.  It needs the
following types of API:

1. Image loaders of three kinds: pass a filename, pass a memory block
   (with the option of passing ownership), or callback which will pass
   in chunks of data - which could be designed around libpng or others.

2. Some means of querying the image to get it's size, and if it is able
   to be rendered in its current state.  These should have some returns
   like DONT_KNOW_YET, NOT_A_VALID_IMAGE, etc.  Also, something so
   generalised data retrival could be handled (for image comments,
   etc.)...

3. A means of returning a cairo image surface with the full, unscaled,
   unclipped contents of the image (if available).  Consumers can do
   whatever they need with this.

4. Some way of saying "Please cleanup some memory", to free decoding
   buffers, the cached image suface, etc.

5. Some way of passing out a cairo surface which could be used as a
   source for operations, but which is not a fully decoded image.  It
   would need to know what cairo backend it was targeting, and then it
   could place a pointer to a backend specific rendering callback in the
   surface.  The backends would then to taught about this pointer, and
   if it was not NULL, call it with enough backend details (including
   transformation matrix and clip path) to enable the function to render
   to the backend surface.  The function would have the option of
   punting, saying TO_COMPLEX_FOR_ME.  The backend would then fall back
   to requesting the full image surface, and use image surface fallbacks
   to render the image.

   This is the point at which the JPEG image backend would add a
   callback if it detected being rendered to a PDF surface, which would
   say "Yes, I know how to put myself into a PDF", and do the magic.

   This would be the only change in the cairo API - an additional per
   surface pointer which would hint to the backend that it had special
   knowledge of rendering.  This isn't such a high price to pay, since
   it could be used by other libraries and it could have other uses.

An image write path would also be nice, but not needed to start with. 
Animation is another topic too.

Of course, this all is not a trivial task.  It would also enable future
work such as Robert (half jokingly) suggested, such as a new X server
extension which allowed one to pass raw JPEGs or PNGs to the server, and
let it do hard accelerated decoding.  It would also enable things like
using enlightenment's Epeg library to do thumbnailing of JPEGs if the result
surface was small, or using jpegtrans to handle special cases of 90deg
rotations.

Mozilla's libpr0n would be a good place to start, although it would
require redefining the API into C.  One could also get lots of code and
ideas from GdkPixbuf, Imlib/Imlib2, and all of the other libraries out
there...

And no, I'm not planning on working on this...

Regards,
  -Jeremy