# Tag Archives: synctex

## TeXlive on Windows: forward and inverse search

Yesterday’s post ended with a conjecture: TeXlive should be able to generate correct sync info on Windows. Today I decided to test that conjecture; I installed TeXlive 2011, which turned out to be surprisingly simple, with one caveat: the MiKTeX installer adds its binary directory to the system path, and if you run the TeXlive installer in user mode you obviously can’t change that. To fix this, you need to add the TeXlive binary path manually, before the MikTeX path. However, if you plan on using Sublime Text 2, you don’t even need to do that, and you can use both distros  side-by-side: read on.

Supporting TeXlive/Windows in the LaTeXTools plugin turns out to be trivial. You only need to modify the LaTeX.sublime-build file! Chalk that up to Sublime Text 2’s build system design, which my plugin’s makePDF command takes advantage of.

I’ll push the changes (commented out, so the default is still MikTeX) soon; for the time being, if you want to experiment, with TeXLive, modify the “windows” section of the file LaTeX.sublime-build so that the “cmd” option looks exactly the same as it does in the “osx” (i.e. Mac) section. This is not surprising: after all, the underlying TeXlive distro is the same. Furthermore, you can use the “path” option to specify the TeXlive binary directory, so you don’t even have to mess with environment variables (make sure to add “;\$PATH” after the TeXlive path).

The result is that Sublime Text 2 now works happily with TeXlive! So, does synchronization (forward and inverse search) work, even with file names that have spaces? Yes! Well, I should be precise.

First, the .synctex.gz file is correctly generated. Recall that MikTeX 2009 does not generate it if the file name contains spaces, so this is an improvement.

Second, forward search works beautifully [an aside: Ctrl-Shift-J is now bound to a folding operation, so I need to change the keyboard shortcut. Use Ctrl-B for the time being: if no compilation is required, the net effect is the same, i.e. you jump to the right position in the PDF file. Again, I’ll push a fix soon].

Third, backward search (from the PDF to the tex file) sort of works. The problem is that the most recent version of synctex “extends” file paths so that

`C:\Users\YourName\Documents\test.tex`

becomes

`C:\Users\YourName\Documents\.\test.tex`

(the same is true on the Mac, btw). Clearly, both paths point to the same file. However, when you double-click in the PDF file, SumatraPDF invokes Sublime Text 2 (or whatever editor you designate) with the second, longer version of the the file name. Now, most likely, you already have the file test.tex open in a tab in Sublime Text 2; however, if you opened that file yourself (e.g. from an Explorer window, or from the Open dialog), the path name associated with the file is the first, “normal-looking” one. As a result, Sublime Text 2 opens a second tab, with the same actual file, but a different path name (the “extended” one). You can check for yourself by hovering on the two tabs: the path names are indeed different, as described above. On the positive side though, the cursor is positioned correctly, corresponding to the point in the PDF file where you double-clicked in SumatraPDF.

Now, this is not a Sublime Text problem: the exact same behavior results if you use TeXnicCenter. Furthermore, no such problem exists with Sublime Text 2 on the Mac (with the Skim previewer). Finally, neither Sublime Text 2 nor the underlying Mac OS do anything special to make sure that files of the form

`/Users/YourName/Documents/test.tex`

and

`/Users/YourName/Documents/./test.tex`

are treated as one and the same: you can try this for yourself by opening a file using the two above specifications of the file name from the Terminal.

Bottom line: it is SumatraPDF’s fault. Or, more precisely: on the Mac, the Skim app is smart enough to send a “normal” file name to your text editor when you perform an inverse search. SumatraPDF is not as smart.

Presumably, the problem does not arise if you use MikTeX because it uses a version of synctex that does not use “extended” path names—but that version, unfortunately, does not handle spaces in file names either!

The bottom line is that it’s a bit of a catch-22: either you use MikTeX, but avoid spaces in file names; or, you use TeXlive, but are forced to open files in Sublime Text 2 by using their “extended” pathname. This is easy to do: open your tex file normally, then build it, then double-click in SumatraPDF; when the second tab pops up in Sublime Text 2, close the first, and from then on work in the new  tab. Of course, you can also open the PDF file first, then double-click, and work in the tab that Sublime Text 2 opens for you. Ugly, but functional.

I will report the issue on the SumatraPDF bug tracker. Hopefully it will get fixed in a later version.