Thanks for taking the time to report this bug.
This particular bug has already been reported into our bug tracking system, but we are happy to tell you that the problem has already been fixed. It should be solved in the next software version. You may want to check for a software upgrade.


*** This bug has been marked as a duplicate of 497279 ***

I just realized that this is not a duplicate of bug #497279, and the bug is still present.
This bug is about big endian machines that are still broken.

I'll attach a patch a new patch that actually fixes the issue on all machines. Also it looks to me like libtiff outputs non-premultiplied data, while cairo expects everything to be premultiplied.

Forgot to reopen the bug.

Created attachment 132360 [details] [review]
patch

This patch should be completely platform independent. It contains one other small change, that is to check whether cairo is returning a rowstride of 4*width. If it is not, then the code will currently fall over.

Oh, I realized that premultiplying does not make any sense if the cairo surface does not even support alpha ...

(In reply to comment #5)
> Oh, I realized that premultiplying does not make any sense if the cairo surface
> does not even support alpha ...
> 

So, what is the state of the patch? I also wonder why the first chunk moves #endif.

The patch does not do any premultiplying and should work fine.

The #endif is moved because the code depends on cairo_format_stride_for_width to return width*4. If the rowstride is different, one would need to not only convert the pixel data, but also move it around.

Great, please commit to both branches if it's not hard

Oh, it was much simpler than yesterday ;-)

Committed to both branches.