This is a continuation of Bug 696682. The user reports and I've verified that Ghostscript renders this file without the expected arrows. MuPDF and Acrobat render the file correctly. The command line I'm using for testing: bin/gs -sDEVICE=ppmraw -o test.ppm ./fails_ghostscript_9.19.pdf
This is a partial regression, commits before 6a82ae29ea4826048fc923388f4f59823e3a55c6 render the image with the arrows partially visible (see attached output.png).
Created attachment 12630 [details] output.png
Created attachment 12631 [details] fails_ghostscript_9.19.pdf
Created attachment 12632 [details] simplified PDF file This appears to be a transparency problem (maybe). The original file is quite complex (almost certainly more complex than necessary) making use of shadings and multiple levels of transparency. The attached file has been considerably simplified. The first arrow is now painted quite simply, the second has had the shading used to draw a gradient fill removed, but the ExtGState remains, this ExtGState uses an SMask entry to apply Luminosity blending with an additional Group. The Group is itself a form, containing its own transparency group and using a Pattern to generate a gradient which it applies to a large rectangular fill. In practice it 'appears' that this generates a flat fill, judging by the fact that the data used to generate the Function is all identical. However, removing any part of the transparency causes the problem to go away. Probably one for Michael to investigate.
Spent a bit of time looking at this. So the pattern fill ends up filling the soft mask with a gray value of 2. This results in a very very light arrow. Something is amiss there as the result of the drawing is correct (i.e. the actual drawing of the arrow before the mask is pure black). Digging a bit further.
I have a fix I am now testing for this.
After digging a bit more it appears to me that when we are in a softmask group we should ignore all the embedded ICC profiles. Essentially there is a mismatch in gamma values that is driving this. I will plan to chat with Ken about working in the interpreter to see about disabling embedded ICC profiles for this case as it will be easier to do there.
So using -dOverrideICC fixes the issue. The approach that we should use for this is to enable -dOverrideICC when we execute the softmask group. I talked with Ray and he is going to do this in the interpreter. Which is to push the existing value of OverrideICC, set it true, execute the mask group, and restore the OverrideICC value.
Fixed with commit a34f71c530409a559c4cb35cb1a23296541d53c3