LaTeX reverse (backward) search not fully functional

[Clstei]

SumatraPDF version

3.7.18446, pre-release 64bit is affected.

It looks like older release versions 3.6.1 and 3.5.2 work well.

Description

LaTeX reverse (backward) search does not work if the SYNCTEX file is compressed (with GZIP).

Sumatra-PDF issues a notification "No synchronisation info available"

Reproduce

I prepared a test setup: InverseSearch.zip

1. Configure Sumatra-PDF for reverse search. You can use this code for debugging what is called by Sumatra-PDF: cmd /c echo %f/%l/%c >> p:\sync.log
2. Prepare the right SYNCTEX file, see below.
3. Open my LaTeX-PDF file in Sumatra-PDF: InverseSearch.pdf
4. Double click somewhere in PDF.
5. Sumatra-PDF comes up with a warning message. I would expect that Sumatra evokes a LaTeX reverse search here. (The experimental code should write the file name in the sync.log file.)

In modern LaTeX the SYNCTEX file can be created with different options, compressed or uncompressed.

• uncompressed (works with Sumatra-PDF 3.7.18446, pre-release): InverseSearch.UNCOMPRESSED.synctex
• compressed .gz file (does not work with Sumatra-PDF 3.7.18446, pre-release): InverseSearch.GZIP.synctex.gz
• compressed .syntex file (does not work with Sumatra-PDF 3.7.18446, pre-release) InverseSearch.COMPRESSED.synctex

I provided alternative SYNCTEX files for all these 3 cases. For testing you need to rename them to InverseSearch.synctex or InverseSearch.synctex.gz respectively.

With 3.7.18446, pre-release only the uncompressed SYNCTEX file works.

For me the Latex-Support of Sumatra-PDF is a very important feature. Although I cannot directly contribute to development I am willing to support the programmer(s) with LaTeX expertise. I can provide more LaTeX test files if desired or test other Sumatra beta versions. I even have a VisualStudio 2026 (and can use it).

Thanks

[GitHubRulesOK]

yes was a known issue try 32bit portable or 3.7 pre-release that has the fixes
if forward-search settings are wrong you should see

If the file is correctly named sameas.synctex.gz it will work (no gz=uncompressed, gz=gzcompressed)

[Clstei]

I can now confirm the following:

1. uncompressed SYNCTEX file sameas.synctex works with 3.7.18446, pre-release
2. compressed SYNCTEX file sameas.synctex.gz works with 3.7.18446, pre-release
3. compressed SYNCTEX file sameas.synctex does not work with 3.7.18446, pre-release. Sorry.

With older release versions all three variants work.

I am sure that my reverse search command setting is right. The error message "Cannot start inverse search. Please check command line setting." is not triggering.

What I mean with "it does not work" is that I see another message which translates as "No synchronisation info available" (see above). In cases where "it works" this message does not appear and reverse search operates as expected.

So the problem with 3.7.18446, pre-release is not to get reverse search running on my computer. The problem is that it seems to fail if the SYNCTEX file is gzip compressed and named sameas.synctex (without extension .gz). Does it work on your side?

Are you saying 64bit Sumatra-PDF has different behaviour than 32bit in regards to SYNCTEX reverse search?

[GitHubRulesOK]

the convention is uncompressed synctex files have an extension of .pdfsync or .synctex
Those that like any tar or otherwise that are gz compressed are named as .synctex.gz and go through a decompressor in temporary space to become .synctex and the most recent changes reflect that historic method but with extra internationalised support for those 2 file types.

IF legacy handling was to sniff the compression and handle it differently, then it may count as either old bonus or new regression, but the convention stands --synctex=1 should be opposite to synctex=0 or -1

AS for 3.6.1 32/64 the consensus by others was 32bit portable worked different so even if a gz file without .gz on the end then 3.61 32bit did not seem to have a problem

[GitHubRulesOK]

@kjk i note another pending change to synctex in 3.7.18447 but dont think it has any bearing on this issue so are we classing a misnamed gz file as a regression or can the sniffing be bettered ?
IMHO a gz file should always like a zip or docx declare it is to be slower as decompression is needed, but I am biased against compression unless truly essential.

[Clstei]

The habit to have gzip compressed SYNCTEX files with extension .synctex i.e. without suffix .gz is not my invention. It is part of the SYNCTEX engine. We can expect that some people would use this naming style.

I am quoting:
https://man.archlinux.org/man/extra/libsynctex/synctex.1.en?utm_source=chatgpt.com#TEX_ENGINE_OPTION_-synctex=NUMBER

[TEX ENGINE OPTION -synctex=NUMBER]
If NUMBER=0 or no option is given, no synctex file is created.
If NUMBER<0, synctex files are text files.
If NUMBER>0, synctex files are compressed with gz.
If NUMBER&2, no .gz extension is used.
If NUMBER&4, activate form support, useful for pdftex.
If NUMBER&8, better file compression.

LaTeX distributions like MikTeX implement this as is:
https://docs.miktex.org/manual/miktex-pdftex.html

As far as I understood, for parsing those SYNCTEX files Sumatra-PDF is using the SyncTex source code from https://github.com/jlaurens/synctex/tree/main
Isn't this source code able to handle this optional unpacking of compressed SYNCTEX files on its own? Function _synctex_get_name() from synctex_parser_utils module even has a little logic to detect some magic bytes in order to find out if the file is GZIP or not (because one cannot trust the file extension). That would mean it is not on Sumatra's side to care for all those possible "compression" options.

Personally I am not insisting. If there are reasons why Sumatra-PDF cannot or shall not support gzip compressed SYNCTEX files with extension .synctex i.e. without suffix .gz, then I am fine with that. I do not even need to know or understand those reasons. If this is decision by the Sumatra programmer(s), then I can adapt my Latex workflow to avoid this undesired file extension style. As long as I can do Latex reverse search, I will be happy. Thanks in any case.

[GitHubRulesOK]

I agree --synctex from -15, -14, -13, -12, ...., -2, -1, 0, 2, 4, 6, 10, 14, will ALL be written by editors as without .gz (IMHO wrong for the 5 x +)
Which was why I said conventionally (perhaps not the best choice of words) because most users don't use all the option simply 3 (-1, 0, 1) from the total 31 options.

It is SumatraPDFs internal PDF reading has to compare the text position with the double click and to do that uses a means to read GZIP files that may not be the same as comic books or PDF and as I am not the developer from way back who added the code nor present developers who are updating that, I don't know why there arises a problem with decompression engine.

It will thus be down to Maintainer @kjk to decide what is the desired stance and you rightly point out it is not a given that a GZ file be marked by .ext thus an added slowdown sniffer to confirm file type before GZ file decompression would become essential.

[Clstei]

OK. Agreed.

At all other people who are reading this, maybe because they experience problems or uncertainty with Sumatra-PDF LaTeX reverse search feature: To avoid any issues it is recommended to use only one of the following options for the LaTeX --synctex setting:

• --synctex=0 means OFF i.e. no synctex file will be created, reverse search not possible.
• --synctex=-1 means an uncompressed synctex file, name is "blabla.synctex"
• --synctex=1 means and compressed synctex file, name is "blabla.synctex.gz"

In other words, stick with the "typical convention", and avoid other possible settings.