I have not had time to look into this but the customer reports: I’m trying Ghostscript 9.05 to linearize some pdf files and I found it fails with files I’m testing with, I’m using the following command which used to succeed with Ghostscript 9.00 gswin32c -q –d NODISPLAY -P- -dSAFER -dDELAYSAFER -- pdfopt.ps c:\123.pdf c:\linearized.pdf
(In reply to comment #0) > I have not had time to look into this but the customer reports: > > I’m trying Ghostscript 9.05 to linearize some pdf files and I found it fails > with files I’m testing with, I’m using the following command which used to > succeed with Ghostscript 9.00 Can I have some more details on what is meant by 'fails' here ? Crash, error, warning, incorrect output ? What ?
Bisecting indicates that this commit: http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=8e6d888502506e061241f2cdeb7c3f76d4dfb04f broke pdfopt.
It seems that pdfopt.ps (using pdfwrite.ps, see pdfwriteob)) relies on being able to temporarily write objects with an index greater than the current xref and later update the xref. The commit which treats objects with an index greater than the number of objects in the xref as null breaks this capability and therefore breaks pdfopt.ps A simple solution to this would be to set a magic flag in pdfopt.ps which causes the PDF interpreter to treat objects with too large index numbers as it did before. The alternative is to recode pdfopt.ps which looks like quite a big job to me. Since pdfopt.ps and pdfwrite.ps rely on the PDF interpreter, and the commit which broke them is in the PDF interpreter, I'm reassigning this to Alex to decide what he wants to do about it. My recommendation would be the simple flag, as its quick to do.
Bug 693044: fix pdfopt utility. Disable checking for the max pdf object number during PDF linearisation, because linearisation adds a few new objects to the PDF file. A patch to pdfopt.ps has been committed as: http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=535d11e8a1d667a3d71680b27f18e4a89df98b2d
*** Bug 693247 has been marked as a duplicate of this bug. ***