While investigating image decoders we came across tests_private/pdf/PDF_1.7_ATS/AC8Z61EC_Save.pdf which on the first page seemed to have red specks that were not related to image decoding. I have not confirmed that these are not present in Acrobat on Android. This document is a blendmode testing document and so I rendered each page of the document in several different viewers: gs git commit d824fb03a6, mupdf git commit 0b9904afe, acrobat reader 19.9.2.11371, google drive pdf view 2.19.312.02.34, foxit pdf 7.2.1.1025 and pspdfkit PDF Viewer Pro 4.0.0 gs was run like so: gs -r120 -dDOINTERPOLATE -dQUIET -dSAFER -dBATCH -dNOPAUSE -sDEVICE=png16m -dMaxBitmap=500000000 -dAlignToPixels=0 -dGridFitTT=2 -sOutputFile=page-%02d.png AC8Z61EC_Save.pdf mupdf was run like so: mutool draw -r96 -F png -o page-%02d.png AC8Z61EC_Save.pdf The file README explains more details, but the first page appears identical in acrobat-reader and foxit-pdf, while the renders for drive-pdf-view and pspdfkit both have red specks in the black box border to the right of the d in the text "Modes". ghostscript has the same problem, but also there are swirly black lines and the one above the o in "Modes" shows a green line in the middle which is not present in acrobat-reader. In addition it looks like ghostscript draws the black line above the light green transparent box instead of under it like acrobat-reader. There are further issues with blendmodes on later pages. These are all described in the README. Chris suggested that maybe ghostscript gets the colorspace or blendspace of a (transparency?) group wrong and that all the issues might stem from this one problem.
Since the attachment is too big for bugzilla I have uploaded the archive to bugzilla/Bug702043 in my account on casper.
One issue is that this file uses overprint and you are going out to the PNG device which is not going to support overprint. Did you compare to AR with overprint turned off?
This is a complex case. My commit, https://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=8c432810d36e24613b84f8506ab3929f9d13e612 is supposed to ensure that the pages are drawn in the page group color space. However, I do see that page 10 is not getting drawn in CMYK but RGB which is causing the wrong rendering. Will dig into this. Some of the other diffs are due to overprint not being supported for the PNG device.
This is a complicated test file, and the 'correct' answer is not easy to be certain of. Not only that but my experience using Acrobat (X) shows that Acrobat is, in my opinion, not always correct especially with the on-screen preview. Some of the pages have a page group, which defines a colour blending space, and some do not. For those pages with a blending space the results should be broadly consistent no matter what colour model the output device has. That is, colours might vary but the actual blending should take place in the defined space and so should render the same whether the output device is RGB or CMYK. For those pages which do not have a defined page group the blending space will be that of the device, so results of transparency blending can be different depending if the device is RGB or CMYK. So pages 11 and 12 render differently depending on whether the output device is RGB or CMYK, and this is actually correct (the differences aren't huge but they do exist). Unfortunately my experience of using the Output Preview in Acrobat seems to indicate that this overrides the page group blending space, which can lead to an incorrect preview. I am also not entirely convinced that having Acrobat render to an image is 100% reliable either. The pages are as follows: 1 - CMYK page group 2 - RGB page group 3 - CMYK page group 4 - CMYK page group 5 - CMYK page group 6 - CMYK page group 7 - CMYK page group 8 - CMYK page group 9 - CMYK page group 10 - RGB page group 11 - no page group 12 - no page group 13 - CMYK page group I've been through these and assessed the output as best I can. I believe that there are 2 pages with problems, and in both cases the problem is that overprint is not being applied when it should be. The pages are 1 and 13; both pages have a CMYK page group so blending (and therefore overprint) should be applied in CMYK space. The result may then be converted to RGB but the overprint should still be visible in the CMYK->RGB conversion. On both these pages overprint is not being applied when the output device is RGB. CMYK devices (eg tiff32nc) do render these pages with overprint correctly applied, which suggests to me that the pdf14 device is looking at the wrong colour space (device vs page group) when applying overprint. I've tried working my way through the pdf14 device looking for where overprint is performed and frankly I haven't a clue, so I'm passing this to Robin. Robin, if you're stuck too chuck it back and I'll try again. I suspect that page 13 is going to be easier to work with than page 1 and I believe it's the same problem so fixing either should fix both. To me page 13 looks simpler.
Add