Raising this issue on behalf of the customer. Using the file from bug #689492 and the tiffsep device, the current HEAD code crashes for me. I believe there is already a bug report open for this, bug #689581. However for me, when using a debug build and debugger, (the customer reports the same by 'disabling colour compression') the output is incorrect. The drop shadows under the text are 'inverted'. That is the white area becomes black, and the dark areas become brighter leading to a 'neon glow' effect. The customer says that the two issues are not related but I'm not able to tell for sure. Using: gswin32c -sDEVICE=tiffsep -o empm2m.tif ests689492m2m_cp_wan_vpn.pdf causes the crash or incorrect rendering for me. I'll attach the PDF file again separately. This has unfortunately been rumbling on for 3 weeks, and the customer has a release being held up by the problem, which is why I've assigned it a high priority. According to the customer this is is also a regression from 8.61, which I'll check shortly.
Created attachment 4092 [details] m2m_cp_wan_vpn.pdf File which causes a problem for me. I will try and reduce this to just a portion of the text with the drop shadow.
Created attachment 4093 [details] m2m-small.pdf Reduced the PDF file to just the form XObjects, transparency groups and images required to reproduce the problem. For me this file produces incorrect output when run under the debugger. Running the release or debug builds from the command line causes a crash.
Created attachment 4094 [details] m2m-small-unc.pdf This is the same as m2m-small.pdf, but uncompressed using pdftk. This exhibits the crash for me when run with the debugger. May be useful for resolving the crash issue.
Created attachment 4095 [details] tiffsep.jpg The incorrect result from tiffsep.
Created attachment 4096 [details] tiff32nc.jpg The expected result from tiff32nc.
Increasing priority for customer issue. I am unable to be sure if this is a regression, the customer says it is a regression from 8.61, but for me the original file on 8.61 renders with the drop shadow completely missing with the both the tiffsep and tiff32nc devices. Which is still not correct of course.
Reproduction notes: On x86_64 linux I get "drop shadow not there at all" with the release build, but with the debug build I see the inverted drop shadow on the tiffsep device as described. In x86 (32 bit) MacOS, the behaviour is similar, except the release build throws a floating point exception on the original file
Entering the customer number, at Guillaume Muller's request.
The customer has very kindly sent me a proposed patch for this problem. In gdevp14.c: 1493,1501c1493,1501 < if ((a + 1) & 0xfe) /* a>=1 && a<=254*/ < { < for (comp_num = 0; comp_num < num_known_comp; comp_num++) < { < comp = buf_ptr[x + planestride * input_map[comp_num]]; < tmp = ((int)a)*comp ; < cv[output_map[comp_num]] = tmp+(tmp>>8) ; /* ~= comp*a*257*/ < } < } else if (a == 0) { --- > if ((a + 1) & 0xfe) { > a ^= 0xff; > for (comp_num = 0; comp_num < num_known_comp; comp_num++) { > comp = buf_ptr[x + planestride * input_map[comp_num]]; > tmp = ((comp - bg) * a) + 0x80; > comp += tmp + (tmp >> 8); > cv[output_map[comp_num]] = comp; > } > } else if (a == 0) { Here is the explanation from the email: "There is a enormous bug in pdf14_cmykspot_put_image(): all transparency levels higher than 50% are inverted when there are direcly mapped to the background (i.e. when there is not a solid color behind). That explains why the bug mostly affected drop shadows, although it's a more general issue. Now, I maintain (more than ever) that the memory problem is a completely separate issue. So you'll maybe have to replace pdf14_compressed_encode_color/pdf14_compressed_decode_color by pdf14_encode_color/pdf14_decode_color to get the correct results with 8.62. As for 8.60 and 8.61, the patch doesn't work so well, but I think the reason is that there was a second bug (more exactly a third one) that has been fixed in 8.62 (and also in my version with the memory leak patch) which was inverting a second time the transparency levels (or maybe the CMYK components). So in fact the 2 bugs were cancelling each other, which explains why sometimes I had correct results with 8.60, and why I thought that was a regression. Another possibility is that this second bug, in fact, has not been fixed, but is completely random and for some reasons is inactive (or at least less frequent) in 8.62. I'll make new tests this afternoon both on Mac on Linux (until now I've tested only on Linux), at different resolutions, and with different files. I'll let you know if I find problems." I imagine this is now considerably less urgent for the customer, since they have a solution, but I think its important to get this reviewed soon.
Created attachment 4137 [details] red25.pdf Additional test file.
Created attachment 4138 [details] red80.pdf Second test file. The customer tells me that with tiffsep the first file (red25.pdf) renders correctly, but the second is inverted.
*** Bug 689814 has been marked as a duplicate of this bug. ***
*** Bug 689829 has been marked as a duplicate of this bug. ***
IMO the best way to fix this and other similar issues is to change ownership of the modules gstrans.c and gdevp14.c to me. I believe that the ownership of the was choosen from scratch, and the current owner would be happy to get rid of them. These modules are not related to colors. Alternatively give them to Alex because me and he collaborate with no problem.
BTW for a better modularity the color blending cycles (a body of which is tried to patch in Comment #9) to be moved from gdevp14.c to gxblend.c . It is about 5% of the module. gxblend.c must definitely be owned by the color specialist.
I'd just like to chime in that this is an issue for us. I've submitted a simple test case to clarify the problem. 100% of a spot color results in black. 80% of a spot color results in very light gray. 20% of a spot color results in very dark gray. In this case the spot color is called "Spot Color Purple" and has a display alternate of purple CMYK.
Apologies -- I somehow put my attachments on the wrong bug. SimpleTiffSepTest.pdf http://bugs.ghostscript.com/attachment.cgi?id=4404&action=view sep.s0.tif http://bugs.ghostscript.com/attachment.cgi?id=4405&action=view Created using: gswin32c -sDEVICE=tiffsep -dBATCH -dNOPAUSE -dTextAlphaBits=4 -dGraphicsAlphaBits=4 -r144 -sOutputFile=sep.tif SimpleTiffSepTest.pdf Ghostscript v8.63
Passing to Michael for load balancing.
I had included this file msm-small-unc.pdf in my soft mask testing. Verified crash and I am now include tiffsep in my testing.
Actually, I don't see the crash with m2m-small-unc.pdf .
All ran except for sep.s0.pdf which failed. Acrobat reader complains about this file as being corrupted though. The softmask rendering issues in m2m-small-unc.pdf and related (which are the original bug source files) do occur with the trunk. They are however properly rendered with the soft mask branch (with out clist rendering). The file SimpleTiffSepTest.tiff shows an issue with the colorant percentages being wrong. The hues appear correct but the tint levels are not correct. I will take a closer look.
Found the problem. gx_put_blended_image_cmykspot was improperly inverting the alpha channel. Should be fixed with r9308.