Created attachment 60394 [details]
source

Created attachment 60395 [details]
the luatex generated synctex output

Created attachment 60396 [details]
the pdftex generated synctex output

Created attachment 60397 [details]
generated pdf

Hi,

have a look at the luatex generated synctex output. It has a full path in the source line, but you try to evoke synctex (embedded in okular) with a relative path. That doesn't seem to work. There doesn't seem to be anything else wrong with your synctex output. You can use the synctex command line tool to play with it yourself and you will find that it finds the synctex nodes once you provide a path that matches the source entry. 

Try to set up your latex environment such that it calls okular with the same path as it writes to the synctex file. That should solve your problem.

Cheers,
Jochen

Thanks for looking at it. That is of course a possible solution, I guess i will do that until the parser is patched to accept all possible ways to specify it.

The same problem happens with pdflatex in texlive2011. Synctex now produces filenames of the form "<path>/./<filename>". Although these are correct pathnames, okular does not recognize them correctly and does not jump to the specified line. 

IMO the filename parser of okular should be fixed to recognize all syntactically correct pathnames.

The work-around described by Jochen does not work when okular is called from a third-party tool, e.g., kile.

Also, is it possible to change the title of this bug, because the bug is more general than the current title suggests? E.g., "okular's synctex filename parser is broken".

I think you are partly confusing which program is doing what. The synctex file (<name>.synctex.gz) is written by pdflatex (or luatex) and specifies a path to a source file. Pdflatex (or luatex) writes this path and decides whether to use a relative path, an absolute path, or even a path that needs expanding. 

Okular does no parsing of source file paths. It simply passes the path you specify on the commandline to the embedded synctex library which in turn reads the synctex file. It looks like this library only supports exactly matching paths, in particular no path expansion. That is not a problem in okular (although theoretically okular could try to provide a workaround).

My comment above points out that in the absence of better support through the synctex library and unless somebody writes a source file path parser for okular, you will need to configure your latex environment (pdflatex/lualatex and your mechanism for calling okular) to provide matching source file paths. This workaround applies in all cases, including when you are using kile.

Seems to be fixed in okular 0.13, openSuSE RPMs of KDE 4.7. The synctex library seems to be fixed with version 1.15 (according to its changelog).

This is an incredibly annoying problem.

I updated Okular to 0.13 and the "command-line synctex" I'm using reports that it's version 1.15. But I am still experiencing the same trouble trying to use forward search with Okular (both from within Emacs and from the command-line) with pdf files compiled with TeXlive 2011---namely that it doesn't work. 

Has anyone any idea of a solution or a work-around?

(I've tried using the file's full path when calling Okular, and it doesn't make a bit of difference.)

The only suggestion I have is to look at the .synctex.gz file. The source file path is listed in one of the lines labelled "Input" (usually the first). Match that path on the okular commandline (you might have to match it exactly as printed).

According to the synctex changelog, 1.15 supports a prefix of "./" (as used by lua(la)tex) but only on windows platforms, 1.16 supports it on all platforms. Texlive 2011 seems to use a different syntax.

I would appreciate if you could report back on your findings so we can get a better sense of what the actual problem is. Thanks.

I don't know why it works with the openSuSE okular 0.13 rpm. From the source file it seems that it uses synctex 1.9 + several patches. Perhaps one of the patches fixes it, but I don't know which one...

ugh... when it worked I may have used an "old" .synctex.gz file. So it may not be fixed in my okular version after all. Sorry for the confusion.

Jochen is right: if I use the exact name, including "./" in referencing the tex file, I can get it to work from the command line, using a new .synctex.gz file and the new synctex command line program.

E.g., 

"okular --unique my-file.pdf#src:50/path/to/my/tex/file/./my-file.tex"

correctly goes to line 50.

How to write the appropriate command in emacs lisp is a different question, however.

In linux, the synctex filename parser compares just the plain strings using strcmp. For windows it actually compares the filenames character in a loop and gets rid of case sensitivity and treats "/" and "\" equivalently.

So here is a non-developer's dirty fix:

In generators/poppler/synctex/synctex_parser_utils.c, function  _synctex_is_equivalent_file_name I replaced the part between "#else" and "#endif" with with the following:

#       else
next_character:
        if(SYNCTEX_IS_PATH_SEPARATOR(*lhs)) {/*  lhs points to a path separator */
                if(!SYNCTEX_IS_PATH_SEPARATOR(*rhs)) {/*  but not rhs */
                        return synctex_NO;
                }
                for (; *(lhs + 1) == '.' && SYNCTEX_IS_PATH_SEPARATOR(*(lhs + 2)); lhs += 2);
                for (; *(rhs + 1) == '.' && SYNCTEX_IS_PATH_SEPARATOR(*(rhs + 2)); rhs += 2);
        } else if(SYNCTEX_IS_PATH_SEPARATOR(*rhs)) {/*  rhs points to a path separator but not lhs */
                return synctex_NO;
        } else if (!*lhs) {/*  lhs is at the end of the string */
                return *rhs ? synctex_NO : synctex_YES;
        } else if(!*rhs) {/*  rhs is at the end of the string but not lhs */
                return synctex_NO;
        }
        ++lhs;
        ++rhs;
        goto next_character;
/*    return 0 == strcmp(lhs,rhs)?synctex_YES:synctex_NO; */
#       endif


This is just a copy of the windows part of the code minus comparing uppercase symbols plus 2 for-loops taken from the sumatraPDF code (http://blog.kowalczyk.info/software/sumatrapdf/free-pdf-reader.html)

Perhaps it's  not very clean, but it works for me...

Philipp, can I suggest that you report that upstream to the synctex developers? My understanding is that there is a new version 1.16 that already tries to fix this. It would be a shame if your fix would conflict with that. From okular's perspective, I think we want to use upstream synctex unchanged so will probably wait until a newer synctex version is available (this is not my call of course but that of the okular maintainer).

I sent an e-mail to the synctex developer.

As a side note, I think (and I didn't realize this previously) synctex version 1.16 is trying to fix something else, namely to remove leading occurrences of "./" as opposed to arbitrary substrings of the form "./".

I have found a work around for auctex and okular.

A possible work around in emacs is as follows using okular. 
Change the okular command in Tex View to 

okular --unique %o#src:%n%(dir)./%b

There is no expander to give the current directory as far as I can see. 
But you can define a new expander in Tex Expand List.
I.e go to Customize AUCTeX ... TeXCommand ... Tex Expand List and add one. 
and save:

I used:

Key: %(dir)
Expander: (lambda nil default-directory)

Many thanks, jenshnielsen!  That seems to work!

Cheers!

jenshnielsen's solution for emacs doesn't work if you have organized your files in subdirectories.  The following, which is based on code from Jochen, works for me:

(add-hook 'LaTeX-mode-hook '(lambda ()
			      (add-to-list 'TeX-expand-list
					   '("%u" Okular-make-url))))
(defun Okular-make-url () (concat
			   "file://"
			   (expand-file-name (funcall file (TeX-output-extension) t)
					     (file-name-directory (TeX-master-file)))
			   "#src:"
			   (TeX-current-line)
			   (expand-file-name (TeX-master-directory))
			   "./"
			   (TeX-current-file-name-master-relative)))

The okular command in Tex-View then has to be changed to 

okular --unique %u

HTH,
olli

Oliver's solution works only for directory names without spaces. Is there something that can be done for the ones that have spaces?

Does anyone know a solution for okular+kile using pdflatex?

Below is a quick workaround that works with kile+okular and probably can accommodate any other <editor>+okular. I only tested it with one TeX file, so it may break with more complicated filenames, but it should be easy to extend.

Now, can you please vote for that bug? I'm surprised that I am the only one who voted for it. It's status is still UNCONFIRMED, which is also suprising.

Workaround for kile:
(1) make sure you have "sed" (should be installed by default on most linux distros)

(2) Create a file, say "<homedir>/bin/fwokular.sh", which the following script:

#!/bin/bash
target=`echo $1 | sed -e "s%\(.*\)/\([^/]*$\)%\1/./\2%"`
okular --unique "$target"

(3) Configure okular's ForwardPDF to execute "<homedir>/bin/fwokular.sh" with the option '%absolute_target'

The shell script just replaces the last occurrence of "/" in '%absolute_target' with "/./" and then calls okular.

Thanks! It works.

(In reply to comment #23)
> Below is a quick workaround that works with kile+okular and probably can
> accommodate any other <editor>+okular. I only tested it with one TeX file, so
> it may break with more complicated filenames, but it should be easy to extend.
> 
> Now, can you please vote for that bug? I'm surprised that I am the only one who
> voted for it. It's status is still UNCONFIRMED, which is also suprising.
> 
> Workaround for kile:
> (1) make sure you have "sed" (should be installed by default on most linux
> distros)
> 
> (2) Create a file, say "<homedir>/bin/fwokular.sh", which the following script:
> 
> #!/bin/bash
> target=`echo $1 | sed -e "s%\(.*\)/\([^/]*$\)%\1/./\2%"`
> okular --unique "$target"
> 
> (3) Configure okular's ForwardPDF to execute "<homedir>/bin/fwokular.sh" with
> the option '%absolute_target'
> 
> The shell script just replaces the last occurrence of "/" in '%absolute_target'
> with "/./" and then calls okular.

(In reply to comment #23)
> It's status is still UNCONFIRMED, which is also suprising.

Well, it is not really a bug in okular (cf. my comment #8 above). IMHO this needs to be "fixed" in the (upstream) synctex library, and even there it is more of a wish then a bug. Synctex in its current state does not support path expansion (with the exception of a leading './' since version 1.15/1.16). You can't expect a tool to magically do something it does not support. Kile does just that by writing one form of path into the synctex file and then calling the viewer with a different path. You could call this a bug in kile. It is irrelevant that the paths containing '/./' are "valid". They need expansion which is currently not supported. 

I would change the title and/or status of this bug to more closely reflect this but I am not the owner (and not the okular maintainer).

To be honest i lost track of what the bug is about, i don't use latex at all so most of the things you speak about are quite obscure to me but as I read some of the comments it seems to me this is a problem on how the paths are generated by third party tools and if those paths are generated correctly everything works.

Now if there is some other !Okular tool that is able to understand those paths, then it'd be a fault on our part.

So please if there is someone that can summarize what the situation is and give a very exact steps to reproduce the problem (if there is actually one) i can try to fix it.

Created attachment 64048 [details]
The test pdf file

Created attachment 64049 [details]
synctex file

Created attachment 64050 [details]
LaTeX file

Albert, thanks for willing to work on this. Here is how to reproduce the bug: Move the 3 attachments I just created (stest.*) in a directory <dir>

Call (exact syntax and filenames is important):
> okular file:<dir>/stest.pdf#<num><dir>/./stest.tex

where <num> is one of 6,12, or 18. The correct behaviour is that okular shows page <num>/3 (i.e., page 1,2, or 3, resp.)

The bug manifests itself if you call
> okular file:<dir>/stest.pdf#<num><dir>/stest.tex

(The difference is that "/./" has been removed from the path.)
In this case, okular always shows the same page, no matter what <num> is.

The expected behavhiour is, however, that okular should also show page <num>/3.
LaTeX editors (such as kile) call okular using the 2nd syntax, and thus fail to open the correct page.

The bug can be easily fixed in okular itself (see my Comment #15). Essentially, in the file generators/poppler/synctex/synctex_parser_utils.c the method _synctex_is_equivalent_file_name has to be made a bit more intelligent.

saved files in lalala folder
 okular file:lalala/stest.pdf#18lalala/./stest.tex
and
 okular file:/home/kdeunstable/lalala/stest.pdf#18/home/kdeunstable/lalala/./stest.tex
open okular in the first page

Sorry, my bad. Please gunzip stest.synctex.gz and at the top of stest.synctex, replace the path in the line starting with "Input1" with your path.

Also, when you call okular, add "src:" after "#", like so:
> okular file:<dir>/stest.pdf#src:<num><dir>/./stest.tex

Albert: Just a bit of information how these files are generated. The author of a document creates the .tex file, and then runs LaTeX on it. That creates the output .pdf file together with the .synctex.gz. With editors such as kile the author can point to a certain position in the .tex file, and okular should open the .pdf file at the corresponding page.

Git commit b932ef7e0fbd96bbb04aafca22c1c936847e5fe2 by Albert Astals Cid.
Committed on 30/09/2011 at 20:47.
Pushed by aacid into branch 'KDE/4.7'.

Comparing paths with strcmp is not really smart

I don't know if Dirk has already tagged 4.7.2 or not so it will be in either 4.7.2 or 4.7.3

BUGS: 274294

A  +22   -0    generators/poppler/synctex/patches/08-fix_path_comparison.diff
M  +1    -0    generators/poppler/synctex/patches/series
M  +10   -1    generators/poppler/synctex/synctex_parser_utils.c

http://commits.kde.org/okular/b932ef7e0fbd96bbb04aafca22c1c936847e5fe2

It seems it ended up in 4.7.2