Created attachment 6792 [details] Patch that forces transparency. Some objects get halftoned in a strange way (on a grayscale device!) when transparent rendering is forced. This happens only on 64-bit AMD64. 32-bit x86 is fine. gs -o foo.pgm -sDEVICE=pgmraw -r300 fts_17_1700.pdf Although the problem happens with a JPX image, there are other files where it happens elsewhere. Resolution of this problem is important for SMaskInData progress. Valgrind reports a couple of uninitialized writes to clist. Similar errors are reported on 32-bit x86 without causing the bug.
From Alex, this will be applicable to the customer once we recognize the 'Alpha' flag in the JPX data and set SMaskInData. I will discuss the approach I have in mind for this with Michael, but I think it should not be too difficult to handle this. The initial concept is to catch this image type a pdf14_begin_typed image and if SMaskInData is set, then create (push) a maskbuf for the SMask, but just initialize it to 'transparent'. Then when the image data is being processed, put the 'alpha' channel into the maskbuf, and process the other N components as usual. One complication is that we have to make this work through the clist, preferably in high-level image mode. An initial implementation may be to have the clist punt on this case (as it does on so many others). I'll discuss this with Michael tomorrow when he is back and post follow up design details here. If Michael is available, he might do this, otherwise, I understand the transparency and image code well enough to tackle it for the customer code, leaving the 'final' implementation to Michael after his vacation.
This looks OK now, both the fts_17_1700 output and the simplified file now match Adobe Acrobat 9 output. Not sure when it got fixed. Anyone interested can play with git bisect. The customer's original problem was fixed some time ago in their code.