Home / SyncTeX’s inverse-search failing - could Sumatra be contributing?

I raised an issue on StackExchange about broken inverse-search in SyncTeX, somewhere between TeXworks, SyncTeX, SumatraPDF and \input files in pdfLaTeX.

The ultimate diagnosis was determined to be an xform somehow contributing to a SyncTeX file that confuses SumatraPDF (the specific line is identified in the thread).

An issue has been raised with SyncTeX but I’ve been advised to raise it here too, in case SumatraPDF might be misinterpreting the SyncTeX file (TeXstudio and its native PDF viewer perform inverse-search correctly).

Thanks!

SumatraPDF will very simply
only be able to respond to sync entries in the compiled .sync(.gz) that follow the given compiled locations. If an entry is missing /misplaced or not formed as expected it cannot use them for recall.

It is common in some cases for \inserted \included \input objects to have a large area of interest but one syntex block entry. Thus often clicking say the middle of an image group the revered call may not always go to the expected source body part, but goto start or the end of that source block entry.

Without the sample to check I have to say from guessing if two alternate source groups have only one synctex entry covering one half, then only that one will be available for use .

Note SumatraPDF is still bound by the older pre 2017 synctex legacy constructs (thus would not be able to use any newer synctex syntax a compiler may add)
see J Lorens comment and the reply