Bugzilla – Bug 690253
"pdfmake destination page" error while splitting a PDF: confusing output and invalid links.
Last modified: 2013-08-09 05:51:33 PDT
While attempting to split a PDF in two using ghostscript, specifying
-dLastPage=N where N is smaller than document's last final page number, I
receive the error:
"GPL Ghostscript 8.62: ERROR: A pdfmark destination page M points
beyond the last page N."
where M is some destination page.
Specifically, I am trying to split any of the Python Documentation pdf's, and
this error occurs on all that I try. The result, as best I can describe, is a
pdf document with some functional links & bookmarks, and others that do nothing.
The problem is that the Error output led me to believe that the process was
failing completely when it was not. I was also not able to find any
documentation about this problem.
The enhancements I'd like to suggest are:
A) that this be a (minimally) documented scenario,
B) that the error output be more helpful (explaining that a semi-functional pdf
was created), and
C) that the invalid links be removed from the output document (links not
hilighted or clickable in pdf viewers).
I will attach a small example pdf so you can test for yourself. The full
command I am using is:
gs -dSAFER -dBATCH -sDEVICE=pdfwrite -DNOPAUSE -sPAPERSIZE=halfletter
-dFIXEDMEDIA -dEmbedAllFonts=true -sOutputFile=test.pdf -dLastPage=740
Created attachment 4757 [details]
This is a test file that produces the error. It is from the official Python
Documentation at http://docs.python.org/
I agree that the message should be a 'WARNING:' (not ERROR) and that it should
say that the PDF produced will have links connected to non-existent pages (or
As far as removing the links, that's up to Ken. Can a link that is broken just
point to its own page location (effectively no-op)?
I'm sure we could point the broken link to its own page, but I was hoping to
remove it altogether. Bit more complex, and I haven't really figured out whether
I also think that we should make -dDOPDFMARKS=false work in this case too, which
it doesn't... It seems that the presence of the pdfwrite device overrides even
an explicit declaration.
I believe this is completely resolved in current code with commit 010e9990d734a8a2361663338b1fbd605d0ca052