Bugzilla – Bug 690422
Acrobat 9.0 PDF Portfolio files cannot be read
Last modified: 2011-09-18 21:45:55 PDT
The attached PDF Portfolio file, produced by Acrobat Pro 9.0.0, cannot be read by Ghostscript head
(r9645); instead of producing the expected output a single page that says "For the best experience, open
this PDF portfolio in Acrobat 9 or Adobe Reader 9, or later.".
The command line I'm using for testing:
bin/gs -sDEVICE=tiff24nc -o test.tif ./publix_1311._structural.pdf
Note that Apple Preview produces the same output as Ghostscript, Acrobat 8 produces the same message,
but then allows you to page through the various pages to view the actual PDF pages.
Created attachment 4937 [details]
This is a PDF file collection without a default document.
The expected result is a list of included files that the user can click on
and view separately. I wonder what Ghostscript should do in this case.
My thinking is that Ghostscript should concatenating the documents in the order they are listed and
generate a multi-page output file.
I think we should check the version of Ghostscript and if it is not the latest,
tell people that "This document is best processed with Ghostscript X.XX, please
upgrade to that version for the best result." ;-)
Seriously, I agree with Marcos, we should just process the files in order.
Created attachment 5171 [details]
This is a work-in-progress patch. It modifies .tempfile operator to avoid
leaving large number of temporary files in the /tmp directory when
Ghostscript terminates abnormally.
We already have complains that pdfwrite leaves many temporary files in /tmp.
Extraction (and decompression) of individual components of the Portfolio
document will create more temporary files of larger size. The patch addresses
Created attachment 5172 [details]
This is a simple implementation that extracts all documents from PDF portfolio
to temporary files and displays them in the order they are listed
in the portfolio.
This patch is useful by as it is but I plan to add command line options
to examine the content of PDF Portfolio and select the files for processing
in the near future.
The patch is not backward-compatible; default document declaration is ignored.
The patch from the comment #6 has been committed as a rev. 9826.
Regression testing shows no differences; the test suite has no PDF
This is adequately resolved by the fix (rev 9826).
If we want to track the enhancements as an issue in the bug tracker, we (Alex)
will open a new issue.
Created attachment 5399 [details]
Raises syntaxerror using GS8.70, no errors when processed by GS8.64
Something is wrong here, guys.
Embedded files may not necessarily be PDFs, a typical example is the attached
embedXML.pdf, which is derived (hacked) from a PDF generated by Quite Imposing
In this case the embedded file is an XML, which obviously doesnt’ have (%PDF-)
string hence a syntaxerror is signaled in pdfopenfile.
Due to this problem, lots of PDFs generated by Quite Imposing Plus plugin
cannot be processed by Ghostscript – unlike Acrobat Reader, which lets
attachments open using the appropriate applications rather than treating them
I recommend the following as immediate workaround:
Let pdfopenfile (and pdfopen, runpdfbegin in turn) have one more boolean
argument on stack to specify whether the file to be processed is an attachment
or not. In case of attachments, non-PDF files should be leaved alone – rather
than treating them as corrupt PDFs.
Skip non-PDF files during enumeration of embedded file streams in PDF
portfolio. Thanks to Zoltán for the sample file.
The following patch has been committed as a rev. 10143.
Regression testing show no differences.
Changing customer bugs that have been resolved more than a year ago to closed.