Version: 0.8.2 (using 4.2.2 (KDE 4.2.2), 4.2.2-12.fc10 Fedora) Compiler: gcc OS: Linux (i686) release 2.6.27.21-170.2.56.fc10.i686 PDF documents support cross-document hyperlinks: A hyperlink in one document can lead to another document. Clicking it will bring up the other document. Okular supports this, but with a bug: When clicking a cross-document hyperlink, Okular will correctly open the new document but will not hop to the correct page. It just stays on page one. Attached are two PDF files documenting the bug: xr01.pdf contains two hyperlinks to xr02.pdf. Clicking the reference to "page 2" sends the viewer to page 1 of xr02.pdf. (Try opening up the documents in Evince instead of Okular to see the correct behaviour.)
Created attachment 33465 [details] Two PDF documents with cross-document links. Two PDF documents with cross-document links. The link to "page 2" works in Evince, but not in Okular.
Confirm. This happens because in case of GoTo actions referring to an external file/document, we just request KDE to open the default handler for the document (basing on its file type); this has the disadvantage that we ignore the associated target information for the newly open document. I see two possible solutions for the problem: 1) use the "PDF Open Parameters" syntax by extending the document URL; I'm not sure how well could be received by other programs though 2) instead of invoking the default KDE handler for the external file, check whether can be handled by Okular and in case open in a new Okular window; could not respect KDE settings for mimetypes though (other ideas?)
Ahh no, please scratch what I said above. The reason is that the "GoTo" actions in the test document specify the destination in the target document with a "named" destination, which poppler(-qt4) tries to resolve in the local document (failing), and thus giving no destination.
SVN commit 967542 by pino: Add the concept of "next destination" next to the "next viewport" one. This allows a resolution, if set, of that named destination when opening a document. CCBUG: 192032 M +28 -4 document.cpp M +7 -0 document.h M +2 -0 document_p.h WebSVN link: http://websvn.kde.org/?view=rev&revision=967542
The remaining part of the fix is in the Poppler library (which we use for PDF documents), and in its Okular backend. Unfortunately, this means waiting for Poppler 0.12 (which will be released in two months), and that Okular's distro package is recompiled against that new version.