View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0000665 | luatex | luatex bug | public | 2011-05-27 08:47 | 2013-12-19 13:57 |
Reporter | kaste | Assigned To | Taco | ||
Priority | normal | Severity | minor | Reproducibility | always |
Status | closed | Resolution | fixed | ||
Platform | probably any | OS | linux | OS Version | opensuse 11.4 |
Product Version | 0.70.1 | ||||
Summary | 0000665: Luatex produces wrong synctex output | ||||
Description | Luatex'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 Reproduce | Take 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 Information | I 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. | ||||
Tags | No tags attached. | ||||
|
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?) |
|
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/ |
|
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). |
|
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 |
Date Modified | Username | Field | Change |
---|---|---|---|
2011-05-27 08:47 | kaste | New Issue | |
2011-05-27 13:04 | Taco | Note Added: 0000863 | |
2011-05-27 13:04 | Taco | Assigned To | => Taco |
2011-05-27 13:04 | Taco | Status | new => feedback |
2011-05-27 14:44 | kaste | Note Added: 0000864 | |
2011-05-27 14:44 | kaste | Status | feedback => assigned |
2011-05-27 14:59 | Taco | Note Added: 0000865 | |
2011-05-27 14:59 | Taco | Status | assigned => resolved |
2011-05-27 14:59 | Taco | Resolution | open => no change required |
2011-05-29 08:43 | kaste | Note Added: 0000870 | |
2011-05-29 08:43 | kaste | Status | resolved => feedback |
2011-05-29 08:43 | kaste | Resolution | no change required => reopened |
2013-12-19 13:57 | Hans Hagen | Status | feedback => closed |
2013-12-19 13:57 | Hans Hagen | Resolution | reopened => fixed |