Open GoogleCodeExporter opened 8 years ago
Thank you for reporting this bug, and thank you for attaching the sample input
PDF. I could reproduce the problem. Indeed there is something wrong in
Multivalent, and pdfsizeopt doesn't recover from it. I'll take a closer look
later.
Please note that the Galois.pdf you have attached seems to be invalid: evince
can't display page 37 properly, see the attached screen shot.
In order to isolate bugs in pdfsizeopt, could you please upload a valid sample
PDF (possibly by regenerating it without page 37) for which it fails?
In the meantime, you can run `pdfsizeopt --use-multivalent=no' (without the
quotes) as a workaround, but it won't fix your PDF if it was already broken.
Original comment by pts...@gmail.com
on 26 Feb 2013 at 5:13
The attached Galois.pdf file is corrupt: object 136, of /Length 3781, contains
a corrupt (uncompressible) /FlateDecode stream.
The behavior and output of pdfsizeopt is not defined when it receives invalid
input (such as Galois.pdf). All I can do for this issue is improving the error
message pdfsizeopt prints a bit.
To get this PDF optimized, please regenerate it correctly first, or run it
through a converter which removes invalid parts, and run pdfsizeopt only after
that.
Original comment by pts...@gmail.com
on 27 Feb 2013 at 7:46
Hi, Peter.
I just got another copy of the document from the author and this new one is
fine.
I guess that what we can take from this episode is that pdfsizeopt could print
an error message instead of dumping a stack trace.
Thanks.
Original comment by rbr...@gmail.com
on 27 Feb 2013 at 8:30
pdfsizeopt indeed prints a useful error message ``Multivalent generated empty
output (see its error above).''. It also prints a stack trace, which is even
more useful, because it can be copy-pasted to the issue tracker. Removing the
stack trace would make it less useful, thus worse. Making this particular error
message (or the corresponding Multivalent error message) more useful would be
too much work. Maybe I could add an ``Is the input PDF corrupt?'' clause here,
but that's also too much work to do consistently, because PDFs can be corrupt
in many ways. The easy improvement is to add the following sentence to the
documentation: ``If your input PDF is corrupt, pdfsizeopt may succeed or it may
fail, possibly with an error message which is difficult to understand. If you
think your PDF is correct, then please report a bug in the pdfsizeopt issue
tracker.''.
Do you have any specific suggestions how to better report the failure in this
particular case?
Original comment by pts...@gmail.com
on 3 Mar 2013 at 8:08
Original issue reported on code.google.com by
rbr...@gmail.com
on 26 Feb 2013 at 2:44Attachments: