Created attachment 11647 [details] Zip file contains sample AI and PDF file. Hello, We are using ghostscript tool to convert Adobe Illustrator (AI) & PDF files to JPEG using these commands. Commands - gswin64 -sDEVICE=jpeg -sOutputFile=a.jpg -dBATCH -r300x300 -dNOPAUSE a.pdf gswin64 -sDEVICE=jpeg -sOutputFile=g.jpg -dBATCH -r300x300 -dNOPAUSE g.ai With GS9.16 version, generated image is not of good quality(there is loss of glosiness). Same works good for GS9.15 or GS 9.14 version. Attached is the sample file. Can you please let us know plan to fix this? Thanks, Atul
Bisecting shows the first bad commit to be: http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=a2d08f1eb Which means this passes to Ray (sorry!).
Created attachment 11671 [details] a.jpg I just generated these, and while the colors differ it's most likely that the code is correct and the difference is due to the original files (.ai vs pdf)
Created attachment 11672 [details] g.jpg
(In reply to Ray Johnston from comment #2) > Created attachment 11671 [details] > a.jpg > > I just generated these, and while the colors differ it's most likely that the > code is correct and the difference is due to the original files (.ai vs pdf) This output is incorrect, or at least its markedly different (*much* darker) than the output of 9.15, which matches the display in Acrobat and MuPDF. Ignore the .ai file, just look at the PDF file in Acrobat.
re-opening at Chris's insistence since the colors are different to Acrobat.
Actually MuPDF clearly is wrong with this file, almost certainly because the file uses transfer functions in at least some graphics states. This might also be a clue to the GS problem, I think there may have been some changes regarding transparency and transfer functions ?
Created attachment 11674 [details] AR9_vs_GS916.png I've reduced the file down to a couple of operations that show (at least one example of) the problem. The attached shows Acrobat 9 vs GS 9.16 with the reduced file (to be attached). This shows part of the wristband that paints a shading in K then blends a pattern on top of it. I'll continue to see if I can reduce this further to see if the problem is due to the use of the Pattern or if it is a problem in the /BM /Multiply used by the pattern. The reduced file does: q 324.376 523.772 -31.557 26.67 re W n q /GS0 gs -0.0000012 -26.6699219 -26.6699219 0.0000012 308.5976562 550.4423828 cm BX /Sh0 sh EX Q Q /CS0 cs /P0 scn 292.819 523.772 31.557 29.321 re h f The Sh0 is uninteresting in that it can be anything that paints a gradient or pattern of grays. The CS0 is trivial, simply specifying a ColorSpace of [/Pattern] The P0 pattern is the interesting bit since it does: 0.258 0.426 1 0.043 k /GS0 gs 601.672 0 -601.672 788.664 re f 0.008 0 0.207 0 k /GS1 gs 601.672 0 -601.672 788.664 re f where GS0 is << /BM /Color /CA .8 /Type /ExtGState /ca .8 >> and GS1 is << /BM /Multiply /CA 1 /Type /ExtGState /ca 1 >> If the final 'f' is changed to 'n' (a newpath which doesn't fill and clears the path) then we match Adobe, so the problem is the /Multiply fill in the Pattern causing a darkening of the colors. Note that filling with 0 0 0 0 k for that fill is almost the same -- we darken and Adobe does not. At least it will be easier to track down now.
Created attachment 11675 [details] b.pdf shows difference to Acrobat with: gswin32c b.pdf
Just to clarify (for future reference), the difference we're interested in is between rendering the PDF with Ghostscript 9.16 compared with earlier releases (I used 9.14 as I happened to have it available) - *not* the difference between the .ai and the .pdf files.
*** Bug 696069 has been marked as a duplicate of this bug. ***
Hello, Is there any update on this issue?
The problem still occurs in the current master branch of Ghostscript. Versions 9.07 .. 9.15 look fine.
On a hunch I tried this file and the PDF now renders as expected (matches Acrobat and the 9.15 rendering). I don't know when it was fixed, but the 10.03.0 release is correct.