Created attachment 102863 [details] PDF file containing some anchors for verification Since okular (>=0.99.80) the forward search or 'named_destination' feature in okular seems to be broken. When trying to open a pdf at a named destination, e.g., through emacs and synctex, I get the following output in stdout: $ okular mypdf.pdf#page.3 org.kde.kcoreaddons: doesn't know ".../mypdf/mypdf.pdf#page.3" org.kde.kcoreaddons: doesn't know ".../mypdf" and I get the error "Could not open file:///[..]/mypdf.pdf%23page.3". The same command works with okular 0.26.1. I suspect that something was changed in how okular processes its command line arguments: In the error message '#' got replaced with the HTML code %23.
I can confirm this bug on KDE Neon (user edition), okular package version 4:16.12.0-0neon+16.04+build1
Can confirm bug on my Arch Linux setup as well. Okular version 1.0.0. (KDE Frameworks 5.29.0, Qt 5.7.1)
This is due to some changes in the way QUrl::fromUserInput works. As a workaround, you can prefix the path by `file:' (even for relative paths!) and get the correct behavior. For example, the following works for me although the original example does not: $ okular file:mypdf.pdf#page.3
(In reply to Thomas Tuegel from comment #3) > This is due to some changes in the way QUrl::fromUserInput works. As a > workaround, you can prefix the path by `file:' (even for relative paths!) > and get the correct behavior. For example, the following works for me > although the original example does not: > > $ okular file:mypdf.pdf#page.3 If you look at the original comment by Peter, you will see that that absolute paths are used. This works: $ okular "file://<absolute_path_to_pdf>#named_destination" When using relative paths, omit the //. This does not work "file://<relative_path_to_pdf>" while this does "file:<relative_path_to_pdf>" The problem is rather that '#' gets replaced with '%23'. i.e. the following does not work: $ okular "file://<absolute_path_to_pdf>%23named_destination"
I looked through the issue, the problem is that there's a safe-guard so that files containing a # in the name won't be misinterpreted. Example. Something like: "okular /.../my#document.pdf" Shouldn't be opening the document "my" with a tag "document.pdf". I don't know who or why it was done. Now you are passing a tag with a dot in it, so the code thinks you're passing a document named: "mypdf.pdf#page.3" with "3" as an extension. Now if you ask me, the weird thing is that we're taking into account the possibility of a file with a # in its filename, but then I barely have experience in the area.
(In reply to Aleix Pol from comment #5) > I looked through the issue, the problem is that there's a safe-guard so that > files containing a # in the name won't be misinterpreted. > > Example. Something like: > "okular /.../my#document.pdf" > Shouldn't be opening the document "my" with a tag "document.pdf". > > I don't know who or why it was done. > > Now you are passing a tag with a dot in it, so the code thinks you're > passing a document named: "mypdf.pdf#page.3" with "3" as an extension. > > Now if you ask me, the weird thing is that we're taking into account the > possibility of a file with a # in its filename, but then I barely have > experience in the area. I haven't seen a file with a hash in its name, but that doesn't mean there aren't any. Some filenames are really weird :-) What about trying to first open the full filename (e.g. 'mypdf.pdf#page.3') and if that fails, try opening 'mypdf.pdf' and finding the dest page.3?
Git commit b13fc1d3be97a8e02884acad6495efa8f13975cc by Albert Astals Cid. Committed on 15/01/2017 at 23:33. Pushed by aacid into branch 'Applications/16.12'. Readd test for file existance when opening files with # on the path M +28 -2 autotests/shelltest.cpp M +3 -3 shell/okular_main.cpp M +17 -5 shell/shellutils.cpp M +4 -1 shell/shellutils.h https://commits.kde.org/okular/b13fc1d3be97a8e02884acad6495efa8f13975cc