Comment 5 for bug 1218350

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.