Created attachment 21937 [details] Input file that produces the incorrect output When converting an Adobe Illustrator file that contains a linear gradient with more than two color stops to EPS, the output file contains white where the gradient should be. If you create a gradient with only two color stops, the output is correct. Example command line: gswin64.exe -dBATCH -dNOPAUSE -sDEVICE=eps2write -sOutputFile=output.eps -f input.ai
Created attachment 21938 [details] bad output
In fact this is nothing to do with ps2write the exact same problem can be seen when rendering. I don't know what you think is in the file, there is not a single shading (or gradient) there are 3. One of them is in DeviceRGB the other two use different spot colours; Emerald Green and Forest Green. The Orange spot seems to be used only to fill the background. If you rename the .ai file to .pdf you will be able to open the file in Adobe Acrobat. Do this and look at the thumbnail; it shows exactly the same result as Ghostscript and that thumbnail was generated by Illustrator itself. If I remove the Optional Content from the PDF file then it renders the green area. I'll look at why the optional content is not being rendered, but it seems to me this is the source of your problem. For what it's worth the old and new Ghostscript PDF interpreters, MuPDF and Chrome (so that's 4 entirely different PDF consumers) all behave in exactly the same way so I very much doubt this is a bug in Ghostscript, I believe this is something to do with the way your file has been created. [Later] The file has two marked content specifications; MC0 and MC1. It initially starts with MC0 and draws an Orange fill. It then switches to MC0 and draws three complex paths each of which is filled with a different shading. Finally the content finishes by closing MC1 and then closing MC0. MC0 is defined (in the page Properties) as being object 10, which is an Optional Content Group named 'Layer 1'. The Optional Content Properties dictionary contains an optional content group for object 10 and it defaults to ON so we draw that marked content. MC1 is defined (in the page Properties) by object 18, which is an entirely empty dictionary. So there is no way for us to determine whether the content should be rendered or not. Clearly we choose not to do so, as does every other PDF consumer I have tried with the notable exception of Acrobat. This appears to me to be a bug in Adobe Illustrator and I suspect you should report it as such. I'll leave this open for now as I may choose to alter our own behaviour in the face of a non-conforming file such as this, simply because it's an Adobe application and Acrobat behaves differently. If it was anything else I'd say the file is wrong (which I believe it is) and ignore it.
OK after much more investigation..... It turns out that the real problem here is that the shading is drawn twice, and uses Overprint. If you view the original file in Adobe Acrobat Professional, select 'Output Preview' and then uncheck the 'Simulate Overprinting' box, then you get exactly the same effect, the green area becomes white. There are in fact three separate shadings here, One in Emerald Green, then one in Forest Green, then one in DeviceRGB which is actually a pure white. Because Overprint is true, when producing Separations the DeviceRGB won't knock out the separation inks. And that's what the 'simulate overprinting' of Acrobat does. If you were to actually try printing this on an RGB device, or a CMYK device without the Separation inks, then you would get the same result you do with Ghostscript, because converting to CMYK would ignore the Overprint, and you would end up with the Seaparation inks being overwritten with white. Now, if we had a ps3write device, we would be able to preserve the Shadings (which are a level 3 PostScript feature), and this would work. However ps2write is only a level 2 PostScript device, and so it is unable to preserve the shadings. In order to reproduce them in the output they are rendered to an image. The act of doing so converts the Separation inks to the device space (RGB or CMYK) with the result that overprinting no longer takes place and the colours are overwritten by the white shading. There is no solution to this other than creating a ps3write device which I'm afraid isn't likely. Note that even without the white overwriting shading, the rendering of the shadings means that they would lose their separation inks anyway, so the result wouldn't be what you expected if printed on a device supporting those inks. But the real problem is the way that the PDF has been constructed and the fact that it relies on Separation colours and overprinting.