Created attachment 11153 [details] Very minimal test case When LockDistillerParams is true, and we call setpagedevice within a save/restore block, the restore fails as below: Error: /rangecheck in .installpagedevice Based on the Adobe docs it sounds like LockDistillerParams should not cause any failure it should just cause requested changes to be ignored. Also I'm not sure whether it should interact with setpagedevice like this. This is tested with version 9.14 on Windows 7 32-bit as below. gswin32c.exe -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -sOutputFile=test.pdf -c "<< /LockDistillerParams true >> setdistillerparams" -f test.ps The attached file is as minimal as I can get. Our real world usage is to provide 2 input files (the saved Adobe Distiller options, and the PS file produced from a document composition tool). If the restore or setpagedevice lines are removed it works, and regardless it does produce a working file but we prefer not to just ignore error messages in our automated processing environment.
The problem is the insane setpagedevice implementation. When we restore back to the state prior to the setpagedevice (page device configuration is affected by gsave/grestore), we set the page device by using .installpagedevice which insists that all the keys must be processed (unlike normal setpagedevice). Now we store the distiller params in the page device structure, so they too (properly) follow gsave and grestore. The problem is that if LockDistillerParams is set, pdfwrite doesn't bother to process the distiller params. This leaves the keys unprocessed and so .installpagedevice throws an error. The only solution is to have pdfwrite process the keys even when its going to simply throw them away. This will impact performance slightly (but only when LockDistillerParams is true as otherwise we would always process these keys anyway) and means revising a lot of code. Since it doesn't stop anything working, making it minor.
Thanks for the explanation Ken. I think in our situation disabling LockDistillerParams should be a safe and convenient workaround for now. I don't think print files should really be messing with the settings much anyway.
I believe that commit 201ff60b950912c09d22b3b4ed0b57ed75c3587a should resolve this.