stackunderflow in .setdistillerparams

That is the correct behaviour. Previous versions ignored the error, and produced the incorrect output.

This is not a bug......

I should add that the previous bug was with without "UseCIEColor" pdfwrite could not access/create device independent colours, hence was emitting a PDF with device dependent colours despite the "UseDeviceIndependentColor" setting.

The reason UseCIEColor has to be set explicitly, and can't be done as part of the "/printer" PDFSETTINGS is that the PDFSETTINGS is a parameter (or set of parameters) for the pdfwrite device, whilst UseCIEColor is an interpreter parameter.

Unfortunately we can't simply add -dUseCIEColor to the 'PDFSETTINGS' (as has been suggested previously) because the PDFSETTINGS are a collection of distiller parameters, and UseCIEColor is a PostScript parameter.

I still hope to get proper colour management for pdfwrite into the next release, and the requirement to add -dUseCIEColor to the command line should go away at that time.

Not a bug according to the Ghostscript developers.

Frankly: if a change breaks an existing behaviour, it is a bug, even if the existing behaviour is an unintended/"wrong" one in the first place.

Downstream users have relied on the existing behaviour and breaking it causes pain. In my case, I was using ghostscript to merge customized books of black & white documents. I know I could have used pdftk for the merge, but AFAIK pdftk can't optimize file weight by subsetting the embedded fonts, so I chose to rely on gs.

I appreciate the attempt to "get proper colour management" for the next release. In a previous life I did photographic work and know how critical colour management is. I am extatically happy to see colour management trickle down to all corners of FLOSS image processing and I am thankful to you guys for the work you are doing.

Nevertheless, this change in behaviour wasted one hour of my time and Murphy's law has it that it was at a time when I could not afford it because I was putting together dozens of such customized books against an application submission deadline, and while I usually have at least two machines available, this time I was on the road and had the laptop only. All of it my fault, no doubts. Just trying to get you to understand a user's perspective hoping that in the future you will consciously try to mitigate such pain rather than ignore the consequences of your changes on others.

A more elegant sequence to fix the "real bug" would have been to wait for pdfwrite to be fixed. Then the "invalid bug" would not have generated pain and confusion downstream.

Thank you for reading and for being more careful next time.

For the reasons yuv stated, this is a bug.

I'm using a python library which called ghostscript just fine before this update, but now doesn't work thanks to this new behavior. I'm sure most users don't want to spend the time editing any applications which call ghostscript in order to make them work with the new version.

cliddAs "gs -sDEVICE=pdfwrite -dPDFSETTINGS=/printer

Sorry, forget the previous comment.

Status changed to 'Confirmed' because the bug affects multiple users.

This affects also inkscape LaTex formula Extension.