Created attachment 14248 [details] Sample PDF file showing bookmark bug When certain PS documents are converted to PDF via ps2pdf, the internal page bookmarks are all off by one in some PDF viewers, such as Okular and Evince. For example, take the attached document test.pdf, which was produced by running ps2pdf on the attached test.ps. Regardless whether you use the document's own hyperlinks in the left-hand column of the page, or the PDF table of contents exposed by the PDF viewer, clicking on "A" takes you to slide "B", "B" takes you to slide "C", and "C" takes you to slide "D". The problem was reported to the Poppler developers. According to them the problem is introduced by Ghostscript in the PostScript to PDF conversion. A detailed explanation is available in the Poppler bug report at <https://bugs.freedesktop.org/show_bug.cgi?id=102698#c1>.
Created attachment 14249 [details] Source PostScript file
OK so the bookmarks are not 'off by one'. According to what the URL you posted says, the XYZ location is different, which causes evince to display it differently when you select continuous mode. That's actually quite a different thing altogether. I'm not certain its even possible for us to preserve a null null XYZ destination but I'll look into it, as an enhancement.
(In reply to Ken Sharp from comment #2) > OK so the bookmarks are not 'off by one'. Well, perhaps I should have prefaced that with "apparently". In the version of Okular I was using, the bookmarks behave as if they're pointing to the wrong pages. Other users reported the same behaviour with Evince: <https://bugs.kde.org/show_bug.cgi?id=370949#c2> The Poppler developer observed somewhat different symptoms in Evince and had a go at explaining the underlying cause, which I don't purport to fully understand. > I'm not certain its even possible for us to preserve a null null XYZ > destination but I'll look into it, as an enhancement. Thanks.
Apologies here, this is going to seem like I'm brushing you off, but the Poppler developer is only half correct. It is true that the Outlines pdfmark (/OUT) has a named destination where the XYZ values are all null, but he has missed the fact that the PostScript file contains later specific named destination pdfmarks. These override the definition of the Outline pdfmark destination (because they come later) and in these cases the XYZ values are not all null. In fact they produce destinations which match fairly well the numbers in the Poppler response. SO no, Ghostscript (or more accurately the pdfwrite device) is not corrupting the information, its correctly using the later information to create a correct named destination. I've attached a copy of the PDF file produced by Acrobat, which produces the same named destinations for me as Ghostscript does. I'm not in a position to test this, so I was hoping that you could try this file the same way you tested the Ghostscript produced file. If you get the same result then you can go back to the Poppler people and ask if they think Adobe Acrobat is also mangling the file, or if perhaps there is some other problem. Both the Ghostscript and Acrobat produced PDF files work perfectly well for me in Adobe Acrobat.
Created attachment 14282 [details] Output PDF file from Adobe Acrobat Distiller X
(In reply to Ken Sharp from comment #4) > It is true that the Outlines pdfmark (/OUT) has a named destination where > the XYZ values are all null, but he has missed the fact that the PostScript > file contains later specific named destination pdfmarks. These override the > definition of the Outline pdfmark destination (because they come later) and > in these cases the XYZ values are not all null. > > In fact they produce destinations which match fairly well the numbers in the > Poppler response. If the destinations in the PDF match the ones in the PostScript file, then the ones in the PostScript file must also be wrong. So the problem must be earlier in the pipeline used to generate this file. It was produced using the powerdot class for LaTeX, so the problem must either be with powerdot or one of its dependencies (hyperref, etc.), with LaTeX, or with dvips. > I've attached a copy of the PDF file produced by Acrobat, which produces the > same named destinations for me as Ghostscript does. I'm not in a position > to test this, so I was hoping that you could try this file the same way you > tested the Ghostscript produced file. If you get the same result then you > can go back to the Poppler people and ask if they think Adobe Acrobat is > also mangling the file, or if perhaps there is some other problem. Thanks for producing this file. I can verify that it behaves the same way as the one produced by ps2pdf. Sorry to have wasted your time with this. I had originally reported it to the powerdot maintainers, but the issue got bounced to Okular, then poppler, then here, whereas it probably should have stayed with powerdot.