The customer's file renders quite slowly (which may be the normal PDF 1.4 limitations) but the output is not correct.
Created attachment 42 [details] PC_AI9_transparency_raster_AI.zip
The image is still different than Adobe Acrobat Reader shows, but I am not sure if it correct. I don't have Illustrator 9 or 10 to see what it shows. The image3x handling would sometimes check mask.InterleaveType even though this was not initialized if mask depth was 0 (that mask was not being used). This could result in data garbling and hangs. I'm not sure why the file sometimes ran 'slow', but I was able to get consitent results using -Z@ which woudl define the mask InterleaveType to an invalid value. The customer reported 20 minute times. I see 2:20 on casper to the bitrgb device and 3:30 on my system to a 24-bit RGB display at 96dpi (same resolution and bit depth as I used on casper). The time for Adobe Acrobat Reader to display the file was 65sec on my system (a 2:1 performance difference isn't horrible like a 20:1 performance difference would be). Interestingly the time for a debug version on casper was 3:57 and 3:30 on my system. The gcc compiler may have superior optimization. I was able to reproduce infinite loops without the fix. Rather than adding a check for mask[i].depth > 0 in a couple of places, I just set the InterleaveType to 0. As long as it is not interleave_separate_source or interleave_chunky, everything works as far as I can test. The patch for the UMR part of the problem is: --- src/gximag3x.c 7 Oct 2002 08:28:56 -0000 1.13 +++ src/gximag3x.c 28 Mar 2003 18:06:29 -0000 @@ -385,6 +385,7 @@ if (pimm->MaskDict.BitsPerComponent == 0) { /* mask missing */ pmcs->depth = 0; + pmcs->InterleaveType = 0; /* an invalid type */ return 0; } if (mask_height <= 0)
With the following patch (to be committed soon, pending regression results from recent commit), the file renders correctly: http://www.ghostscript.com/pipermail/gs-code-review/2003-October/004190.html Rendering is still slow, but it is also slow in Acrobat Reader 5. Thus, I am closing the bug. We will be doing further speed optimizations on PDF 1.4 rendering.