[cairo] Not sure how to handle MIME in my go binding

[Adrian Johnson]

On 11/05/14 08:50, jimmy frasche wrote:
>> Kinda. But you still have to decode the data, it's just that the resulting files
>> could use the mime data.
> 
> In the case of the PNG in the PDF, I imagine the "might" comes from one of:
> 
> - the pdf version does not support embedding that mime type or
> 
> -  the mime is supported but not that particular encoding or format
> (like it can't take transparent PNGs, for an example that's completely
> made up) or
> 
> -  manipulation of some kind to the image, say clipping it, would
> require using the decoded data instead of the mime data.
> 
> Is that correct?

The first two are correct. Unsupported mime types are ignored. The last
one is not correct. PDF (and other vector surfaces) can embed the entire
image then clip it when it is rendered.

There is a third case where the mime data may be ignored. Where cairo
operators that are not natively supported by a backend are used, a
fallback image containing the cairo_image_surface rendering of the
region affected by the unsupported operators is embedded.

The PNG in PDF is probably not a good example since:
 1) The PNG mime is not supported by the PDF surface.
 2) The vector backends can already compress images with similar ratios
    to PNG. The PNG mime just saves having to recompress the data.

The mime data is really intended for use with lossy compression such as
JPEG where decompressing the image and recompressing with Flate results
in a much larger embedded image. If the backend were capable of
recompressing in JPEG the image would be degraded. So there is an
advantage in making the original JPEG data available to the backend for
embedding where possible.

> If so, it sounds like it's only really useful with an ImageSurface
> being used as a source pattern unless your only need is to make a pdf
> containing just the embedded png.

That is the only way it is intended to be used. You still need to
provide the image surface containing the decoded image since it is not
guaranteed that the mime data will be used. By attaching the compressed
image data it is possible for the backend to embed a much smaller
version of the image without any loss of image quality.