Version: 0.10 (using 4.4.00 (KDE 4.4.0) "release 2", KDE:KDE4:Factory:Desktop / openSUSE_11.2) Compiler: gcc OS: Linux (i686) release 2.6.31.12-0.1-default First thanks for having pdf forward search available in okular. However I noticed a small inconsistency between the way okular handles forward search for dvi and pdf documents. I will attach documents which allow to test the behaviour You can use okular test.(dvi|pdf)#src:<line no.>test.tex to run forward search. It also works if you use absolute pathes for your files or relative pathes. However if your relative path starts with './', it only works for dvi files. To reproduce run okular loremipsum.dvi#src:25./loremipsum.tex and compare with okular loremipsum.pdf#src:25./loremipsum.tex with the attached files
Created attachment 41090 [details] example document for foward search
Hi, the mechanisms for dvi and pdf files are very different, so there are likely to be more inconsistencies like this one. For the dvi case there is a whole separate class in generators/dvi/dvisourcesplitter.cpp that handles the splitting and sanitizing of the requested source link. In the case of pdf there are only a few lines of code in generators/poppler/generator_pdf.cpp in the method PDFGenerator::fillViewportFromSourceReference. The result is then passed on to synctex to handle. I guess, the sourcesplitter class could be generalized and then used in both the dvi and pdf cases, but that would require quite some work and careful thinking (like what exactly can synctex handle vs how dvi source specials look like). Why is it crucial that exactly the same syntax works for both cases?
Well, it's not crucial, but it makes sense, same program, same options should apply if possible, and in this case seems that it is possible Jochen you think you can give it a try?
No it is not crucial, but at least Kile hat to change its code for PDF forward search, see https://bugs.kde.org/show_bug.cgi?id=226718 and the Kile maintainer suggested to report this.
Hm, I have been looking into this and as I feared, this is far from trivial. In fact, the syntax that you/kile have been using is not really supported and it only works "by accident" in the dvi case. The source file path you are using, i.e. "./loremipsum.tex", requires expansion to make sense, i.e. the "." needs to be expanded to the current working directory. As far as I can tell, path expansion is not officially supported by other viewers in this context, only relative and absolute paths are. It is definitely not supported by synctex, the library okular uses for forward search in pdf files. So, why exactly does it work for dvi files in okular? The dvisourcesplitter class tries to support common but wrong syntax in forward search command lines, such as missing ".tex" file name extensions and missing spaces between line number and source file name where the latter starts with a digit. It does this by testing the existence of source files. For this purpose it creates a QFileInfo from the given source file name and plays with this (adding extensions, modifying paths and names etc.) in all sorts of manners. Because of the way that QFileInfo works, this process also handles simple expansions like "./loremipsum.tex". The problem I am having with this approach is that it tries to second guess what the user wants and may yield unexpected results in pathological situations (such as nested folder structures with common filenames at several levels or where folder names start with digits). In my view it would be much cleaner if the expansion happened before okular is called (i.e. if kile did it in this case and called okular using either a relative or an absolute path). Summing up, a clean approach would be to do away with the current dvisourcesplitter, expand the documentation of the forward search command line syntax explaining more clearly what syntax is supported, and implementing some checks that warn the user if wrong or ambiguous syntax is used. What do people think? P.S.: I believe the original reason why the dvisourcesplitter class was implemented has to do with file names that start with digits. From old forum discussions concerning xdvi (the first viewer to support all this), it seems to be clear that the supported syntax was meant to be <dvi path>#src:<number>[ ]<source path> where <source path> was either relative or absolute and the blank between <line number> and <source path> was mandatory if <source path> started with a digit and optional otherwise. The problem is of course that such a blank needs to be escaped on a typical unix command line, so somewhere along the way the kdvi developers started to "support" a no-blank syntax despite the fact that this can not be made unambiguous in all cases.
Dear Bug Submitter, This bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? I am setting the status to NEEDSINFO pending your response, please change the Status back to REPORTED when you respond. Thank you for helping us make KDE software even better for everyone!
Dear Bug Submitter, This is a reminder that this bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? Thank you for helping us make KDE software even better for everyone!
Thank you for reporting this issue in KDE software. As it has been a while since this issue was reported, can we please ask you to see if you can reproduce the issue with a recent software version? If you can reproduce the issue, please change the status to "REPORTED" when replying. Thank you!
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!