MantisBT

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000665luatexluatex bugpublic2011-05-27 10:472013-12-19 14:57
Reporterkaste 
Assigned ToTaco 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
Platformprobably anyOSlinuxOS Versionopensuse 11.4
Product Version0.70.1 
Target VersionFixed in Version 
Summary0000665: Luatex produces wrong synctex output
DescriptionLuatex's synctex output is slightly different from pdftex's and is broken according to okular and evince. Both viewers work fine with pdftex's synctex output. For luatex evince just doesn't do anything and okular doesn't either but gives this warning:
SyncTeX Warning: No tag for file.tex
On a side note: the file is mentioned in the synctex output, but i really don't understand the format and couldn't find the specification for it.
Steps To ReproduceTake any random document (of preferably more than one page worth of text, otherwise it's hard to see; i took lorem ipsum twice \bye, no other tex command) and compile it with pdftex --synctex=1 file.tex and it will work; luatex --synctex file.tex won't.
Additional InformationI can provide examples if needed but it works for any random file for me. This issue is still valid, i compiled yesterdays source in order to test it.
TagsNo tags attached.
Attached Files

- Relationships

-  Notes
(0000863)
Taco (administrator)
2011-05-27 15:04

I'll take this up with Jerome Laurens, but I have troubles with the bug report itself: I have not a clue how to enable synctex in either of those programs, and otoh texworks is perfectly happy with luatex's output. Are you *sure* this a luatex problem (as opposed to an evince/okular one?)
(0000864)
kaste (reporter)
2011-05-27 16:44

First of all thanks and wow at your quick reply. I can't really be but i talked to jose aliste from evince and the fact that it worked with pdftex convinced us that it probably is rather on the luatex side.

The other thing is that if i understand Jerome Laurens right in his paper http://www.tug.org/TUGboat/tb29-3/tb93laurens.pdf [^] then the clients are all supposed to use the same parser library. You understand this better than i do for sure but can the viewer really see a difference when all it gets is a request for a certain line, the file and the synctex output? I would conclude it comes down to the synctex output, but i may be wrong.

I will try to check it with skim as soon as i get back to my macbook and give you the results.

The command line for okular is
okular --unique <file.pdf>#src:<linenumber> <file.tex>
for evince you need a script because unfortunately it is based on dbus :(
You can find one here http://jlebl.wordpress.com/2011/01/13/vim-evince-and-forward-and-backward-latex-synctex-search/ [^]
(0000865)
Taco (administrator)
2011-05-27 16:59

Oh, I get it now. You need something like:

    okular 's.pdf#src:4:'`pwd`/s.tex

these days, because the file names in the synctex file are now absolute. It fails in okular & evince because they are reading the source file name from the command line instead of from the synctex.gz (as they should, I think).
(0000870)
kaste (reporter)
2011-05-29 10:43

I filed bugs with both, here are the references

https://bugzilla.gnome.org/show_bug.cgi?id=651263 [^]
https://bugs.kde.org/show_bug.cgi?id=274294 [^]

Thanks for the clarification

- Issue History
Date Modified Username Field Change
2011-05-27 10:47 kaste New Issue
2011-05-27 15:04 Taco Note Added: 0000863
2011-05-27 15:04 Taco Assigned To => Taco
2011-05-27 15:04 Taco Status new => feedback
2011-05-27 16:44 kaste Note Added: 0000864
2011-05-27 16:44 kaste Status feedback => assigned
2011-05-27 16:59 Taco Note Added: 0000865
2011-05-27 16:59 Taco Status assigned => resolved
2011-05-27 16:59 Taco Resolution open => no change required
2011-05-29 10:43 kaste Note Added: 0000870
2011-05-29 10:43 kaste Status resolved => feedback
2011-05-29 10:43 kaste Resolution no change required => reopened
2013-12-19 14:57 Hans Hagen Status feedback => closed
2013-12-19 14:57 Hans Hagen Resolution reopened => fixed


Copyright © 2000 - 2012 MantisBT Group
Powered by Mantis Bugtracker