[cairo] Embedding jpeg in pdf

[Vladimir Vukicevic]

On Jul 18, 2008, at 12:26 PM, Behdad Esfahbod wrote:

> On Fri, 2008-07-18 at 09:59 -0700, Vladimir Vukicevic wrote:
>> 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.
>
> What other jpeg infrastructure do you have in mind?  If native
> win32/quartz stuff, then cairo can just use those too.

Not really sure why it matters -- whether it's win32 native/quartz  
native, or intel's jpeg primitives, or something else, I don't think  
cairo needs that dependency.  Cairo should just have a way of getting  
a jpeg bytestream, or in case of your second point, of being able to  
use a registered jpeg compressor... given that this is a fairly  
specific use, adding a core libjpeg dependency seems unnecessary.  I  
guess it could be ok if load_from_jpeg was optional like the png stuff  
was, but I think that the png code was also a mistake; I don't think  
we should be unnecessarily adding additional cairo API that then has  
to be supported in the future, especially one that depends on external  
functionality, and one that's more of a utility function rather than a  
core necessary API.

     - Vlad

>>> - 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
>>
>> _______________________________________________
>> 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
>