Originally reported by: jackiem@users.sourceforge.net Customer #651 Test file Jon.ai when rendered by ghotsscript has a black sqaure where Acrobat Reader has a camo-colored pattern. File avallable on casper.
Camo is still dark when -dUseCIEColor is forced on (in gxdevice.h), black otherwise.
I've used more recent 'debug' features to determine where at least part of the problem comes from (although there are apparently several). Running with -dPDFSTEP and -dNOTRANSPARENCY shows that the following 'fill' operation paints over a 'camoflage' area with black. /GS0 gs step # 246 ? %Resolving: [27 0] << step # 247 ? /Type /ExtGState /ca 1 /CA 1 /BM /HardLight /AIS false step # 248 ? >> step # 249 ? endobj step # 250 ? 497.077148 347.461914 m step # 251 ? 103.487297 347.461914 l step # 252 ? 103.487297 585.922852 l step # 253 ? 497.077148 585.922852 l step # 254 ? 497.077148 347.461914 l step # 255 ? h step # 256 ? f step # 257 ? With NOTRANSPARENCY, this is not too surprising, but since this shows through when viewed with AR (6 or 7), presumably it should not be an opaque overprint when transparency operations are performed correctly. Since I am able to reproduce this problem I am changing the status to 'NEW" (from "UNCONFIRMED"). I don't know why Jack or Raph didn't do this (other than it is a low priority).
The output of the file (like most files that use overprint) depends upon the process color model of the output device. This file displays correctly if the output device uses a DeviceCMYK process color model.
The problem seems to be that the transparency group specifies a DeviceCMYK color space for the transparency blending. However we currently base the blending space only on the process color model of the output device. If so then the fix involves extending our PDf 1.4 transparency implementation.
No longer a customer
Although the output is much better when output device is DeviceCMYK based, I see a vertical and horizontal line that crosses in the middle of the camoflage area that doesn't appear in Acrobat Reader. Arguments used were: -r100 -sOutputFile=test.tiff -sDEVICE=tiff32nc ~/Jon.ai
Another blend space issue, according to Dan in #4.
Where is the file for this bug? I would like to test with the soft_mask branch.
The file is available from: casper.ghostscript.com:/home/support/578865/Jon.ai
I verified that the color issue is only due to the blending space. The PDF spec clearly states that if a color space is not specified then it inherits from the base device color space. This can also be seen by bring the file into photoshop and picking the color space to use (i.e. RGB or CMYK) and you will see radically different renderings. Passing this bug off to Robin to look into the vertical lines that appear.
Created attachment 7583 [details] Jon2.pdf Simplified version of the test file. All that is left is a hard light blend of a shading.
Changed title from: Colors missing in AI9 file. The remaining problem with this file, is that when rendered we get various 'stray' lines drawn. These take the form of 'cross hairs' with a circle around the outside of the radial fill, and occasional speckles on the image itself. These are due to the fact that shadings do not guarantee to only draw each pixel once. In particular radial shadings draw the pixels falling on the axes twice. For solid plotting this does not matter - for transparent rendering it does. The solution is probably going to be to setup a knockout group around the shading if antialiasing is used. Passing back to Michael, as he's done this before. If the change needs to happen in the postscript, he may well choose to pass this hot potato onto Alex.
Bug still reproducible in Ghostscript 9.03
Fixed with a combination of these two commits: commit 73bd448d2ebabad9ee31053abf897325a639cba1 Author: Robin Watts <Robin.Watts@artifex.com> Date: Thu Sep 19 12:07:00 2019 +0100 Bug 578865: Push transparency group for non idempotent shadings. Shadings that write the same pixels more than once can be rendered incorrectly for blendmodes that aren't idempotent (or for non solid opacities). In such cases, push a transparency group so that the shading can be written just once, and then safely blended. Note that this doesn't capture shadings that are rendered via zshfill. commit 1d1d6dc851e23edb36ac6e5db1bdf0edbba262bd Author: Robin Watts <Robin.Watts@artifex.com> Date: Mon Sep 23 18:52:16 2019 +0100 Knockout groups should knockout the group alpha (and shape) too. When marking within a knockout group, for each pixel we mark, we throw away the current colorant values in the destination, and base the calculations of the new colorant values on the stored backdrop values. We were failing to do this for the group alpha and shape calculations. This could lead to the group alpha getting out of sync with the actual colorant values. We were seeing this with shadings (particularly gradient shadings) where the shadings paint some pixels more than once. This becomes much more obvious with the forthcoming commit to use knockout groups for shadings with either transparency or non-idempotent blend modes.
Followup fix: commit eb7802dc979aaa0e9e43310de0f1e8dcc7b31b2c Author: Robin Watts <Robin.Watts@artifex.com> Date: Wed Sep 25 14:35:00 2019 +0100 Bug 578865: Fix typo Fix typo in previous commit.