As can be seen in the attached screenshot.png our output for the cutter separation differs from the one produced by Adobe Illustrator; Ghostscript renders the bottom two blocks gray instead of black (ignoring the fact that the cutter layer is red in Illustrator). Note that this is with Ghostscript head (68a0f6217428daf297d73589821b62ba2e862d0f), earlier versions of Ghostscript generate entirely incorrect output. The command line I'm using for testing: bin/gs -sDEVICE=tiffsep -o test -r300 ./RBR1101382.pdf Note that the cutter file is test.s4.tif. Also, the test.s1.tif, test.s2.tif, and test.s3.tif separations are also wrong in the same way, but the test.s0.tif file is correct.
Yes, this is a bug in Ghostscript. I changed all "1 scn" and "1 SCN" operators to "0 scn" and "0 SCN" and partly shaded objects have disappeared. This cannot be right. Apparently, /Separation/All color inherits some of tint values from specific separations, drawn earlier.
I stepped through the logic used when we have an All separation color and it seems to be working correctly. Need to simplify this file to narrow down the issue.
It appears that the set color is getting messed up at some point. The tint values to the right of springfield solutions seem to be inherited from that path of text and the star like drawing above it. Since the c code is handling the all filling with a sep color space correctly I am passing to alexcher to take a look to make sure set color is working properly.
Created attachment 7838 [details] simplified example Much simplified example file. The 'FILE No.' at bottom left should be black and is rendered in a shade of gray. Note that there is no text in this file, the text has all been converted to outlines.
Assigning back to Michael as this does seem to me to be a colour problem. Using the attached simplified example, I set a break point in zfill(). On the first occurrence (the grey star shape) I followed the code into gx_set_dev_color and then into gx_remap_Separation. I see that the separation colour (the parameter pcc) is 0.2, as expected. On the second occurence (the 'text') I again followed the code into gx_set_dev_color and into gx_remap_Separation. In this case I see that the separation colour value is 1.0, again as expected. So the PDF interpreter seems to be working correctly. As a further clue that its not the interpreter, two of the spot separations show the 'text' in gray, but one of them shows it as 100% black, as do the 4 CMYK plates. There is no way that this should happen for /All separations. I'm afraid I don't know enough about the colour code to understand how one of the separation plates is getting the wrong colour. I hope it's something simple.
Like bug #692494 the display device correctly shows the output, so it does seem to be a problem specific to the tiffsep device, and it may well be the asme problem in both cases.
I have made a bit of progress in tracking this one down. Thanks to Ken for making the simplified example! What occurs is that we do properly correctly convert /All such that the fill would occur across all the colorants. However, we encode the color during the remap with a compressed color encoding (using tiffsep_encode_compressed_color). Later during the mem_true64_fill_rectangle we take the compressed color encoding and rather than perform a compressed color decode, we simply unpack it as if it were not compressed. This is clearly wrong. Will chat a bit with everyone on this topic after the Tuesday meeting.
As discussed on the phone just now, the mem64 device just fills a rectangle with whatever 64-bits are in the gx_color_index -- never attempts to determine what colorants are what. It is in the tiffsep_print_page that "devn_unpack_row" is used to turn the compressed color back into the individual components.
Right. It appears that the devn_unpack_row may be the culprit. Tracking that down now.
Fixed with http://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=48e7b9e6aaf93eded227a089b94f90db209476ff