Created attachment 6954 [details] image3.ps Bug 691785 is to do with type3 images and interpolation. In investigating that bug I've found a problem with gs handling of type3 images independent of interpolation. As this is somewhat more basic than that problem, I have split this off and plan to investigate this first. I hope that by solving this one, Bug 691785 might get solved in the process. I had thought that ghostscript, could not cope with postscript images of type 3 (those with explicit masking) where the mask is larger than the image data, but a test file I have put together seems to indicate that this is not the case. I attach a simple test file. This renders a series of images across a page. In each case, the image data is an identical 4x4 blue/green square, but the masks differ. The first image is unmasked. The second image has a 4x4 mask of alternate pixels. The third image has a 2x2 mask for alternate pixels. The fourth image has an 8x8 mask for alternate pixels. The fifth image has an 3x3 mask for alternate pixels. The sixth image has an 6x6 mask for alternate pixels. The seventh image has a 3x3 mask for alternate pixels, but the mask transform is such that the mask covers a larger area than the image. The eighth image has a 6x6 mask for alternate pixels, but the mask transform is such that the mask covers a larger area than the image. Ghostscript renders images 1-4 and 6 perfectly. The masks on image 5 and 7 are incorrect. Image 8 is arguably correct too, but it differs from Acrobat. Acrobat agrees with ghostscript on 1-4 and 6. It gets 5 correct too. It renders 7 and 8 identically to 5 and 6. I suspect therefore that there are 2 things to note here. 1) GS has a problem in some cases with the mask being rendered wrongly. I need to establish exactly what the circumstances are that trigger this. 2) Acrobat does not honour the ImageMatrix given in the ImageMask dictionary. I need to do more investigation into 1, but I believe that 2, is because Acrobat chooses to ignore the ImageMatrix given in the ImageMask, and formulates its own based on the relative size of the data/mask. Changing the mask transform within the file seems to support this - Acrobat never changes its output. (Specically, I tested a variety of scales, including horizontal and vertical flips). On the face of it, this seems a sensible thing to do. The PDF and Postscript specs both state that while the image data and mask differ in dimensions, their images under their respective transformations must exactly cover the same area in device space. Ghostscripts code has an inbuilt limitation whereby the image and data must share the same orientation (i.e. one cannot be flipped horizontally or vertically or be rotated from the other). Essentially we have to be able to enumerate scanlines from either data or mask and only cope with relative changes in scale. Given this limitation, and the spec, we could afford to follow Acrobats example here. This would mean that images 7 and 8 would (like Acrobat) come to be identical to 5 and 6. It would also mean that images with unaligned ImageMasks would at least render rather than giving an unhelpful error message as now happens.
Created attachment 6955 [details] image3.ps Corrected test file; I had the ImageMask transforms wrong for 2 of the 8 images. Fixing this fixes 1) entirely. This just leaves 2). I'll rename the bug accordingly.
According to PLRM, the image and the mask should be mapped to the same rectangle. The image that violates the spec is asking for "undefined behavior". MS-DOS, for instance, in such cases used to erase NVRAM area. When Ghostscript converts the sample file to PDF, it uses, like Distiller, the ImageMatrix attribute from the image dictionary. PDF files generated from the sample file by Ghostscripr and Distiller look the same on Ghostscript or Acrobat Reader in any combination. When the PS file is rendered directly by a CPSI-based product (PhotoPrint), Ghostscript and Adobe honor the image matrix, also producing similar images.