[Okular-devel] [Bug 228427] New: inconsistency between dvi and pdf forward search

[Christian Trippe]

https://bugs.kde.org/show_bug.cgi?id=228427

Summary: inconsistency between dvi and pdf forward search
Product: okular
Version: 0.10
Platform: unspecified
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: NOR
Component: general
AssignedTo: okular-devel at kde.org
ReportedBy: christiandehne at web.de


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

[Christian Trippe]

https://bugs.kde.org/show_bug.cgi?id=228427





--- Comment #1 from Christian Trippe <christiandehne web de> 2010-02-25 10:47:23 ---
Created an attachment (id=41090)
--> (http://bugs.kde.org/attachment.cgi?id=41090)
example document for foward search

[Jochen Trumpf]

https://bugs.kde.org/show_bug.cgi?id=228427


Jochen Trumpf <Jochen.Trumpf at anu.edu.au> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |Jochen.Trumpf at anu.edu.au




--- Comment #2 from Jochen Trumpf <Jochen Trumpf anu edu au> 2010-02-25 21:12:00 ---
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?

[Albert Astals Cid]

https://bugs.kde.org/show_bug.cgi?id=228427





--- Comment #3 from Albert Astals Cid <tsdgeos terra es> 2010-02-25 21:38:10 ---
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?

[Christian Trippe]

https://bugs.kde.org/show_bug.cgi?id=228427





--- Comment #4 from Christian Trippe <christiandehne web de> 2010-02-26 08:12:31 ---
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.

[Michel Ludwig]

https://bugs.kde.org/show_bug.cgi?id=228427


Michel Ludwig <michel.ludwig at gmail.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |michel.ludwig at gmail.com

[Jochen Trumpf]

https://bugs.kde.org/show_bug.cgi?id=228427





--- Comment #5 from Jochen Trumpf <Jochen Trumpf anu edu au> 2010-03-07 02:59:19 ---
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.

[Johannes Schwenk]

https://bugs.kde.org/show_bug.cgi?id=228427


Johannes Schwenk <johannes.schwenk at gmail.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |johannes.schwenk at gmail.com

[Andrew Crouthamel]

https://bugs.kde.org/show_bug.cgi?id=228427

Andrew Crouthamel <***@kdemail.net> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|REPORTED |NEEDSINFO
Resolution|--- |WAITINGFORINFO

--- Comment #6 from Andrew Crouthamel <***@kdemail.net> ---
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!

[Andrew Crouthamel]

https://bugs.kde.org/show_bug.cgi?id=228427

Andrew Crouthamel <***@kdemail.net> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|NEEDSINFO |REPORTED
Resolution|WAITINGFORINFO |---

--- Comment #7 from Andrew Crouthamel <***@kdemail.net> ---
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!