[cairo] Embedding jpeg in pdf

[Vladimir Vukicevic]

On Jul 18, 2008, at 4:53 AM, Behdad Esfahbod wrote:

> Instead of commenting on your API right away, let me point out two
> things:
>
>  - What's so bad about depending on libjpg anyway?

Because it adds an unnecessary burden on any users of cairo that are  
not on linux, who either don't care about jpeg reading or (more  
likely) already have their own jpeg infrastructure in place.  It also  
means that even if they use something other than libjpeg for jpeg  
handling, they'd have to pull in libjpeg as well.

>  - At some point we SHOULD be able to compress images as JPG instead  
> of
> PNG when embedding in PS/PDF, so we will need libjpg anyway.

I would do this using a callback mechanism, and let the app use  
whatever jpeg library it wants.

Like I said before, I'm not against a separate cairo-utils library  
that provides implementations of some of this this stuff for those who  
just want a simple one-stop solution, I just don't think that  
functionality should be part of the core.

     - Vlad

> On Sun, 2008-07-13 at 13:53 +0930, Adrian Johnson wrote:
>> One of the items on the ROADMAP [1] for 1.8 is jpeg embedding in the
>> PDF, PS, and win32-printing backends.
>>
>> There are a couple of ways this could be implemented. The minimal
>> approach would be to add a function to supply the jpeg data to a
>> surface. The jpeg data would be used instead of the image data when
>> embedding the surface image in backends that support jpeg. The  
>> advantage
>> of this approach is that no dependency on a jpeg library is required.
>> The disadvantage is that the user would need to be careful to ensure
>> that the surface has the same content as the jpeg image otherwise
>> fallback images are going to be wrong.
>>
>> The other approach is to provide a  
>> cairo_image_surface_create_from_jpeg
>> function. The advantage is a simpler API for applications to use. The
>> disadvantage is the libjpeg dependency.
>>
>> I have created three patches to implement these two ideas on the jpeg
>> branch of my git repository [2]. The first patch adds the API  
>> function
>>
>> void
>> cairo_surface_set_jpeg_data (cairo_surface_t    *surface,
>>                              unsigned char      *data,
>>                              long                length)
>>
>> to supply the jpeg data to a surface.
>>
>> The second patch implements PDF embedding of jpeg images. The third
>> patch adds the API function:
>>
>> cairo_surface_t *
>> cairo_image_surface_create_from_jpeg (const char   *filename)
>>
>>
>> The current limitations of these patches that I am aware of are:
>>
>> - I am not sure who should own the data supplied by
>> cairo_surface_set_jpeg_data() and whether the entire data or only the
>> pointer should be copied when snapshotting surfaces.
>>
>> - cairo_image_surface_create_from_jpeg() does not free the jpeg data
>> when the surface is destroyed.
>>
>> - The error handling in cairo_image_surface_create_from_jpeg() is
>> probably wrong.
>>
>> - A create_from_jpeg_stream function would also be required if we are
>> going to use cairo_image_surface_create_from_jpeg().
>>
>>
>> Any comments on which approach to jpeg embedding we should take and  
>> what
>> the API should look like?
>>
>>
>> [1] http://www.cairographics.org/roadmap/
>> [2]
>> http://gitweb.freedesktop.org/?p=users/ajohnson/cairo.git;a=shortlog;h=jpeg
>> _______________________________________________
>> cairo mailing list
>> cairo at cairographics.org
>> http://lists.cairographics.org/mailman/listinfo/cairo
> -- 
> behdad
> http://behdad.org/
>
> "Those who would give up Essential Liberty to purchase a little
> Temporary Safety, deserve neither Liberty nor Safety."
>        -- Benjamin Franklin, 1759
>
> _______________________________________________
> cairo mailing list
> cairo at cairographics.org
> http://lists.cairographics.org/mailman/listinfo/cairo