Home / Inverse search without synctex

Is there a way to use forward/inverse search without a synctex file?

I would like to synchronize annotations in a 2nd program to SumatraPDF.
What I would like to get is document and page number from SumatraPDF, basically a very simple inverse search without translating to a location in a .tex file.

I have created a program to collect the arguments and set up the inverse search according to these instructions https://tex.stackexchange.com/questions/116981/how-to-configure-texniccenter-2-0-with-sumatra-2013-2016-version , but without a synctex file, nothing happens.

Is there a way around this and send the location in the pdf to another program?

Your link is the older superseded one see https://tex.stackexchange.com/a/453731
As far as I know you have two options

1. SumatraPDF simply notes a synctex file or synctex.gz has the same name and folder location as the .pdf then passes the imbedded filename.tex) to the specified external program (normally but not exclusively an editor) the machine does not need to have a TeX distro installed.

Create your own dummy synctex file (samename.synctex or older .pdfsync) it would be possible to build one manually/text processor but probably a lot of trial and error to get the sync block references correct (without using a normal tex editor)

2. Use the external editor function which can pass the current filename.ext and page number (but not the synctex ref as there is none)

I am trying to make annotation program for pdfs with the notes in a text editor or Word. I want to be able to jump between locations: if I annotate page 11 in the pdf, it is supposed to jump to the corresponding section in the annotation.
Similar to interleave-mode (https://github.com/rudolfochrist/interleave), which uses a pdf viewer that I never got to run properly.

If I use the ExternalViewer (your option 2), I’ll have to go through the file menu each time I would like to make an annotation. The inverse search is much more convenient (just a double click). I’ll look into making my own fake 1:1 synctex file like you suggested. Maybe the format is not that difficult.
Thank you!

To help you build a dummy .synctex here is very malformed minimum (it probably breaks all the synctex rules but works

So my SumatraPDF > settings > options > inverse search command-line is notepad %f %l
and alongside 3page.pdf I have the following 3page.synctex

SyncTeX Version:1
Input:1:./test.txt Page
Output:pdf
Magnification:1000
Unit:1
X Offset:0
Y Offset:0
Content:
!30

{1
[1,1:0,0:0,0,0
]
!0
}1
!9

{2
[1,2:0,0:0,0,0
]
!0
}2
!9

{3
[1,3:4736286,50644704:29685704,550500,235932
]
!0
}3
!9

Postamble:
Count:99
!0
Post scriptum:

You can have more than 1 input so could store/link page 3 comments in input #2 file or if you correctly build the synctex entries have parts of a page go to one location whilst other parts go to other links (but then that’s what adding hyperlinks to a pdf should do.)

Works beautifully! Thank you very much!

For reference, here is the code to capture the output with -inverse-search and the forward search command.

int main(int argc, char** argv)
{
    cout << " argc= " << argc << "\n";
    for (int i = 0; i < argc; ++i)
        cout << argv[i] << "\n";
    cin.get(); // keep window open
    return 0;
}

import win32ui
import dde
server = dde.CreateServer()
server.Create("myClient")
conversation = dde.CreateConversation(server)
conversation.ConnectTo("SUMATRA", "control") conversation.Exec(r'[GotoPage("C:\test.pdf", 1)]')

DDE is generally no longer recommended for forward search see WinEdt comment "PDF macros no longer use DDE for SumatraPDF. Using the command line switch -forward-search is faster and more reliable. Using a command line switch (if it exists) is always preferable (simple is better). Besides DDE does not (and will not) support Unicode! "Major new features in WinEdt 10

1. support life is unknown due to increased OS security restrictions
2. reputedly has more problems with some UTF types of filename (e.g. accented user names / with spaces or other punctuation symbols)

preferred method is call / start (ensure ReuseInstance = true in SumatraPDF-settings.txt file)
with synctex
SumatraPDF -forward-search InternalTarget.ext 1 master.PDF
with/without synctex
SumatraPDF -zoom “fit width" -page 2 -scroll 0,400 master.PDF
or other nav commands e.g. -named-dest “destination name”

I wasn’t aware of this, thanks for letting me know. I’ll change my code to what you suggested.

Hi, there

In my problem, I found that if the .synctex.gz exists, then the inverse search always leads to the error"No synchronization point". In stead, if I delete the .gz and rename the synctex file to .synctex (without.gz), then the inverse research works.

I don’t know why this happened.

Many thanks

.GZ is Gnu compressed so needs an extra decompression step in the process

When compiling the syntex options can in theory be set from -15 up to +15 for a variety of structures, however the “normal” values are -1, 0 or +1 to signal if the file is with .gz or not

Thus there may be an incorrect setting in the TeX IDE , you need to check it there as SumatraPDF will simply respond per the file extension if it is not GZipped but has .gz added in compiler that will cause the issue.

I’m using Sublime 3 + Texlive 2021 + SumatraPDF and tried to use the inverse search.
I have been using it for several years with no problems in my previous machine.
But now I’m trying to use the latest version of SumatraPDF (3.3.4), then it turns out to be “No synchronization point”. I checked the temporary file and there did exist the synctex.gz file. Somehow, when I tried to move the extension .gz (which means renaming the .synctex.gz to .synctex), it works, the inverse search worked.
It’s weird, doesn’t 3.3.4 support the .synctex.gz file?

I moved your related post here as the problem seems to be a setting is not correct in sublime, however I do not know which option in that editor needs changing there should be an option in the compilation something like -synctex=-1 that will need to be checked for setting to no .gz

It is possible that if sublime is using a newer synctex.gz compression method from TexLive 2021 than the older one used by SumatraPDF, then the .gz may in that case be incompatible but that is guesswork without files to compare.

Thanks for your reply.
The setting of my Sublime is exactly the -synctex=1, which indicates the .gz file should be used. It cannot be used for 3.3.4. However, when I uninstall the 3.3.4 and install the older version 3.1.2 and 3.3.3, the inverse search works well with the .gz file.
So I guess maybe it’s the problem of version SumatraPDF 3.3.4?

Not running latex at present I cant look for differences but your logic seems sound

IF you make small line 1=Hello line2=World sample with old working combination as hello333.tex hello333.synctex.gz and hello333.pdf “in the same folder” to avoid path issues then bundle all 3 into zip and add to a report at Issues · sumatrapdfreader/sumatrapdf · GitHub it may be possible the dev @kjk could compare 3.3.3 versus 3.4.pre-rel