I would put the tests outside the for loops over x and y (for speed)

Anything else ? I will merge it in ~12h

• If there is nothing else **

why checking in configure.ac several versions of poppler ? It is a stable API

Thanks for the patch. I will try it when I'll reach work.
I just have a small remarks: wouldn't it be better to remove IMAGE_PIXEL_ITERATOR_END? It will make the use of the iterator less cumbersome

#define IMAGE_PIXEL_ITERATOR \
   for (y = 0; y < crop_height; y++) \
        for (x = 0; x < crop_width; x++)

Plus, in Eina and stuff, we are using the FOR_EACH terminology, so maybe we could have:

#define IMAGE_FOR_EACH_PIXEL \
   for (y = 0; y < crop_height; y++) \
        for (x = 0; x < crop_width; x++)

IMAGE_FOR_EACH_PIXEL
  {
     do->stuff();
     do->another_stuff();
  }

IMAGE_FOR_EACH_PIXEL
   do->stuff();

Also, we could save some calculations in these loops. I can see the same thing is calculated 2 or 4 times (depending of the code path): x+y*crop_width.
I think at the beginning of the loop, you could do:

const int blah = x + (y * crop_width);

and use blah (I have no inspiration for a meaningful name) then.

instead of blah, maybe this is better :

int iter = 0;

int the loop:

dst[iter] = src[iter];
iter++;

Also, src should not be re-assigned at each iteration, must be done before. There is already a scope that can enclose it in both cases.

Actually... the before and after code that copies the pixels seems quite different to me, and changes the previous behaviour? Was there a bug in the previous algorithm?

I mean, before, the iteration was done with: src += width; dst += crop_width; Now, we are affecting both src and dst with crop_width.
Also, using memcpy() is better than doing a copy loop (image::format_argb32).