The attached file (the same as Bug #691152) is converted differently with and without banding when writing to the tiff32nc device (there are also differences with/without banding when using tiff24nc, but they are more subtle). The customer reported this with 8.70 and 8.71 and I've duplicated it with head (r10832) as well. The command lines I'm using for testing: bin/gs -sDEVICE=tiff32nc -o with.tif -dBufferSpace=10000000 38781-359-ART.pdf bin/gs -sDEVICE=tiff32nc -o without.tif 38781-359-ART.pdf
Created attachment 6023 [details] 38781-359-ART.pdf.gz
Created attachment 6024 [details] 38781-359-ART.pdf.gz
Created attachment 6025 [details] without_banding.tif
Created attachment 6026 [details] with_banding.tif
This is a regression, prior to r9331 the file converted the same with and without banding (the file as other issues with both r9330 and r9331 that were fixed in later revisions).
Looking at the log message for 9331, this may be expected as TBD in the transparency code. DETAILS: Previously if a sep device is used when processing a file that contains both transparency and overprinting, the overprinted colors would blow away the other sep colors. In this commit, there was one fix to improper geometry in pfd14_cmykspot_put_image. The remaining changes involve: 1) passing overprint compositor actions to the pdf14 device, which occurs during the clist reading phase (in pdf14_create_compositor) 2) adding over_print and overprint mode to the pdf14 clist parameters (this follows the same process that is currently done for text knockout, blend mode etc) 3) adding the actual fill support in pdf14_mark_fill_rectangle. Even though this was raised by a customer originally, is the remaining issue actually still a customer issue ?
Assigning to Marcos for answer to Ray's question in comment 6.
Customer has been contacted; awaiting a reply.
based on no reply from the customer I'm downgrading this bug and reassigning.
As per my email to tech "banding/page mode bugs", closing this file as I cannot reproduce a problem.