[cairo] Re: Embeding JPG in PDF
reg at FreeBSD.org
Fri Jan 12 11:17:04 PST 2007
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,
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
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
And no, I'm not planning on working on this...
More information about the cairo