zipped synctex fails in 3.4.x

GitHubRulesOK commented 2 years ago

Discussed in https://github.com/sumatrapdfreader/sumatrapdf/discussions/2640

^{Originally posted by **honekamp** May 31, 2022} In older versions of Sumatra PDF, it was possible to have a zipped synctex file and still backwards and forward search would work just fine. Starting 3.4.x, the support for a zipped synctex file seems to have ceased. I have to unzip the synctex file in order to do a forward or backward search. Has this change been applied intentionally? Is there any way to work around the change?

GitHubRulesOK commented 2 years ago

3.4.x exhibits a non working synctex behavior but it is not seen in 3.5 pre-release

kjk commented 2 years ago

Could you write a (really) short tutorial on how to setup some latex editor for preview with Sumatra?

Just the bullet points: "install this software, that software, this is a sample latext project, this is how to configure latex editor to preview that latex project with Sumatra"

Latex support was written by Zeniko, who's no longer contributing.

I kept it and tried not to break it but I don't use latex so it's not tested.

I just need step-by-step instructions on how to setup the most basic latex setup so that I can actually test the code because I'm not familiar with those tools and would rather not spend time reading random docs that might or might not have an answer.

But if there's a from scratch tutorial already out there, then a link to it is good too.

kjk commented 2 years ago

So far I've installed MikTeX (for latex processin) and TeXStudio (some latex IDE).

kjk commented 2 years ago

Created a simple project in TeXStudio and it auto-detected "C:\Users\kjk\AppData\Local\SumatraPDF\SumatraPDF.exe" "?am.pdf" %* as External PDF Viewer.

But what now?

kjk commented 2 years ago

So configured TeXStudio to use SumatraPDF as external viewer so now F5 creates a PDF and opens it with Sumatra.

But I'm not sure where does synctex come into play, what features does it enable etc.

kjk commented 2 years ago

In both 3.3.3 and 3.4 when doing F5 preview from TeXStudio I see the generated file but also "can't open message. Not sure if that's expected.

kjk commented 2 years ago

Ok, I think I got it:

I can use TeXStudio to generate a pdf + .synctex.gz file
In Sumatra I can open this .pdf and when I double click on a word, Sumatra uses .synctex.gz to map location of that word to a position in .tex file and call one of the configured text editors (I have notepad++) to invoke that editor with .tex file positioned at the source.

And it can go from text editor to sumatra but I haven't figured out that part yet.

kjk commented 2 years ago

As noted in https://github.com/sumatrapdfreader/sumatrapdf/discussions/2640#discussioncomment-2859309 I cannot repro this in 3.4.3

So I would need a more detailed instructions on how to repro this.

In general it would be very strange if synctex support didn't work in 3.4.3 but worked in 3.5. If anything, things should break in 3.5.

GitHubRulesOK commented 2 years ago

@kjk Impressed I am took me months to get to know LaTeX configure foibles and years later it still holds surprises.

Anyway I am struggling with this one, as multiple methods I think should not fail are not running as expected. Perhaps I need a reboot in my reverse ? currently few are reverse working but it did ! certainly it should work with any portable exe as I always tested with that in the past.

uncompressed is not a problem only this gz version so searching for other samples

GitHubRulesOK commented 2 years ago

@kj for proving the source.tex and the two compiled files they should always show they were saved at the same time, so as to be assured they are a working set

The editing tex should be able to seek a line in SumatraPDF and highlight per settings, likewise a double click on text (or indexed area) in the pdf should invoke the editor with that line number to be highlighted,

In theory there are perhaps multiple tex files for one pdf and synctex should take that into account by passing the correct Relative file name as well as the line number.

highlite.zip thus this set may attempt to open others listed in the unpacked gz but should not need to call them for the visible core text ?

clicking Title should call line 23 as end of frame rather than 14 which is editor line but clicking other text attempts to go to H:\HOME\Temp\mik30899_src\highlite.vrb line 2 which is not available but used for highlighting in that area !

Its not a good example, but in some cases I am seeing other results or no syncronisation

OK currently every version using cmd.exe /k "echo "%f" %l" as a test will either report line 23 or H:\HOME\Temp\mik30899_src\highlite.vrb line 2

So with my old file there are two very different but correct results

GitHubRulesOK commented 2 years ago

Right it seems like my old compiled file works in all versions

but the OP sample occasionally does not, and I still cannot fathom why its varied in behavior, only sometimes

now OP file is working again without fail so far

kjk commented 2 years ago

It this context, what "doesn't work" means?

What do you do, what happens, what do you expect to happen?

GitHubRulesOK commented 2 years ago

@kjk the OP source file combination frequently on double click in PDF would complain the syctex syncronisation data was not found for that area. it should on unpacking / reading synctex.gz behave same as when the file is uncompressed, but was not and initially seemed to be versions starting 3.4 but they are now behaving, so something on the machine or my configuration is having an effect.

That's why I reverted to a very simple known (dubious highlight with gz file with two alternative behaviors) which was not a problem thus showing the problem seems not to be SumatraPDF versions.

lacorrep commented 2 years ago

I've had the same issue since I updated from 3.4 to 3.5. I uninstalled Sumatra then reinstalled. The "No synchronization info at this position" pops up at random. Here's how I code then compile:

write LaTeX code with Sublime Text
compile using xelatex -synctex=1 -interaction=nonstopmode %tex_file%.tex
try to double click on a line in Sumatra: "No synchronization info at this position". I have to write a large document this summer and this is really slowing me down...

After reading this thread, I've switch to unzipped synctex files (-synctex=-1) and it seems to have fixed the problem. I'll come back to tell you if it persists.

CastleStar14654 commented 2 years ago

Similar problem. But the weirdest thing is: if I directly open the PDF file, inverse search not working; but if the PDF file then get recompiled while Sumatra still opening it, the inverse search would go fine

GitHubRulesOK commented 2 years ago

@CastleStar14654 That can be normal if the synctex is old / bad / missing A fresh compile should sync the pdf with a fresh synctex file, (as long as there was no compile failure)

For tests you need a near matching timestamp on all 3 files

CastleStar14654 commented 2 years ago

@GitHubRulesOK actually I opened it from file explorer just AFTER I successfully compiled it.

GitHubRulesOK commented 2 years ago

@CastleStar14654

Ahh > from file explorer

perhaps you are refreshing editor location during compile thus needs at least one to set inverse editor, I have mine preset to a default for any pdf testing via explorer.

CastleStar14654 commented 2 years ago

@GitHubRulesOK Hi, I re-checked it, and I found that Synchronization file cannot be opened is reported sometimes. And, I could be sure that it is nothing to do with 'a too old synctex file' since at times it works well with a PDF I compiled half a year ago.

Actually, I found that most of No synchronization info at this position happen when Sumatra has just been started from, for example, Start Menu and recovered the previously-opened-files list.

Suppose that last time Sumatra is closed with 'A.pdf' and 'B.pdf' opened, both of which have corresponding *.synctex.gz. With Remember opened files turned on, when I open Sumatra next time, both A and B are resumed. Now, both A and B cannot do inverse-search. Then, if I open a new file 'C.pdf' which also has a corresponding *.synctex.gz, then all of A, B, and C can be inverse searched, even though I did not re-compile any of them. (Here, opening C can be replaced by closing and re-opening A or B. But open a file without synctex does not do the trick)

Edit: something weirder, if I open Sumatra with the -console option, the synctex always works fine;

%LOCALAPPDATA%/SumatraPDF/SumatraPDF.exe -console

if not, it does not work for those restored sessions.

PaulSoderlind commented 2 years ago

just an observation: uninstalling SumatraPDF 3.4.6 and then using the portable version seems to solve the synctex problem. (Win 10, 64)

divenex commented 1 year ago

I've had the same issue since I updated from 3.4 to 3.5. I uninstalled Sumatra then reinstalled. The "No synchronization info at this position" pops up at random. Here's how I code then compile:

write LaTeX code with Sublime Text

compile using xelatex -synctex=1 -interaction=nonstopmode %tex_file%.tex

try to double click on a line in Sumatra: "No synchronization info at this position". I have to write a large document this summer and this is really slowing me down...

After reading this thread, I've switch to unzipped synctex files (-synctex=-1) and it seems to have fixed the problem. I'll come back to tell you if it persists.

I have been having this issue consistently with Sumatra 3.4.6 (64bits). Changing my TeXstudio compile setting from pdflatex -synctex=1 to pdflatex -synctex=-1, to use unzipped sync files as suggested by @lacorrep, fixed the issue for me.

kjk commented 2 months ago

Things changed in pre-release and we've upgraded synctex code.

If still happens, then please open a new bug with reproducible steps.

sumatrapdfreader / sumatrapdf

zipped synctex fails in 3.4.x #2642

Discussed in https://github.com/sumatrapdfreader/sumatrapdf/discussions/2640