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

[jimmy frasche]

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

Yeah I figured there had to be something that would keep it from being
used directly. I should have known that clip wasn't one of them
though.

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

That makes sense. I take it tha

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

It sounds like the best way to handle this in the binding is to have a
separate package that takes an image file and decodes the image and
saves its raw data into a buffer and returns a fully configured
surface pattern created from an image surface. There's no jp2 support
in the Go standard library but I can leave a hook for anyone using an
external library.

That assumes that setting the mime data to null is to just reuse a
surface object more than once. That seems like a good optimization but
keeping the interface simpler seems like a win for a higher-level
binding such as this.

I guess that just leaves the case for how URL's on an SVG surface
work. At this point I'm assuming that it works similarly in that you
need an image surface with the data held at the url being attached?

Since that only works with them I'd likely just have a special type in
that package. Some code duplication but should keep things simpler and
more obvious for the user.

Assuming that's all correct, tomorrow I'll whip up an implementation
of the above and figure out how to clarify the existing docs and post
a draft in this thread.