If PDF contains rotated PNG images, then result JPEG will not contain these images. 1. Take a PDF that has rotated PNG images 2. Convert PDF to JPEG using the following cmd line: gswin32c.exe -q -sDEVICE=jpeg -dBATCH -dNOPAUSE -dJPEGQ=95 -dFirstPage=1 -dLastPage=1 -r300 -sOutputFile="I_980000000001411001_%03d.jpg" "I_980000000001411001_001.pdf" In the result JPEG place of the PNG images is cut.
Created attachment 4832 [details] test.pdf Please test with this PDF.
This seems to be a bug in banded rendering. Adding -dMaxBitmap=300000000 works around the bug for the sample file at 300 dpi.
With the clist, I get a Seg fault during clist playback. The image_begin gets a pis->lop of 0xF0 (instead of 0xfc), which leads to the segfault in gx_make_rop_texture_device. When processing without the clist, the lop in image_begin is always 0xfc. Since this is clist and transparency related (the failure is from the pdf14 device compositor 'put_image'), I will assign this to myself. Also since this is a segfault (at least with a DEBUG build), I am increasing the priority.
I'm surprised this hasn't shown up before. This _was_ seen previously and Igor's rev 8170 alludes to doing something to prevent a similar problem (bug 689186: see DETAILS comment #2 in the log message), but this was NOT the correct solution. When writing the transparency buffer to the target device in the pdf14 POP_DEVICE using the "put_image" proc, we really need to use a ROP that simply allows us to copy the image in 'normal' mode i.e. use rop3_default. The state of the low bits of the clist_playback_band imager_state.log_op is rather arbitrary at the end of the band and not relevant to the put_image operation. The patch (rev 9546) was: --- base/gdevp14.c (revision 9540) +++ base/gdevp14.c (working copy) @@ -1443,7 +1443,7 @@ to prevent a failure ingx_image_enum_begin. */ gs_imager_state new_is = *pis; - new_is.log_op &= ~lop_pdf14; + new_is.log_op = rop3_default; p14dev->pdf14_procs->put_image(pdev, &new_is, p14dev->target); } pdf14_disable_device(pdev);