Oh no! Some styles failed to load. 😵 Please try reloading this page
Menu â–¾ â–´

#136 SyncTeX should always write absolute paths

open
nobody
None
5
2009-10-03
2009-10-03
phi
No

I think that SyncTeX should always output absolute paths. The current behavior is to write relative paths for the input files, which breaks inverse search e.g. in Skim when a different output directory is set via -output-directory. I could easily fix this by having my build script replace all input paths with absolute paths. It would be great if SyncTeX wrote absolute paths right from the beginning.

There has already been some discussion around this issue on the TeX Live mailing list (see http://tug.org/pipermail/tex-live/2009-October/022844.html\), including a few suggestions about whether and when relative paths should be used.

Discussion

  • laurens

    laurens - 2010-03-05

    In fact, the current behavior is to write what TeX gives. This can differ from OS to OS and from distribution to distribution. Adding some filename management to SyncTeX would add too much overhead.
    Given a synctex file, the input file should be searched in the output directory and all the directories above.

     
  • Christiaan Hofman

    No, the viewer cannot fix this problem, it's simply impossible. The viewer knows only about the output file, and from that it can find the .synctex file. The location of the source file is simply not available in the .synctex file, so all a viewer can logically do is /assume/ it's in the same directory.

    Also searching the input file "in the output directory and all the directories above" makes no sense, there's no reason whatsoever that there's such a relation between input and output, as I can set the output directory to whatever I want, even on a different mounted system.

    So in order to fix this, it should be clear that the .synctex file should contain information to find the source file, either by using at least one full path to the source file or directory, or a path relative to the output directory.

     
  • Christiaan Hofman

    There is a genuine bug in SyncTeX. Currently, the .synctex file is placed in the input directory (TeX Live 2009 on Mac OSX). This way, it is impossible for the viewer to find it, because the viewer knows only about the output file as a starting point. And then it does not even matter what info the .synctex file contains, as it can't even be found. So definitely for SyncTeX to be able to work together with -output-directory the .synctex file MUST be placed in the outpur directory (that also makes more sense).

    Second, it must be possible to deduce the location of the input file from the information in the .synctex file and its (or the output file's) location. This is currently not possible, as all paths are given relative to the input directory, which is an unknown to begin with.

    BTW, I do agree that the .synctex file should contain relative paths.

     
  • phi

    phi - 2010-03-06

    In my system (MacTeX 2009 on OS X), the synctex file is definitively placed in the output directory. Quite odd.

     
  • karl berry

    karl berry - 2010-03-08

    Hi Jerome -- how about adding a directive to the .synctex file which gives the cwd of the tex run? Otherwise, it seems to me there is no way for a viewer to find relative-specified files. For instance,

    pdftex --output-directory=/tmp/karl --synctex=1 hello.tex # just one line: hello\bye

    results in a /tmp/karl/hello.synctex.gz that starts with:
    SyncTeX Version:1
    Input:1:hello.tex

    A viewer reading /tmp/karl/hello.pdf has no way I can see of tracking that hello.tex back to its input directory.

    This wouldn't require doing anything with the filenames (I don't like the idea of making them absolute either), but just adding one small item to the synctex file.

    Wdyt?

    FWIW, the .fls files written by -recorder include a similar PWD directive, for the same reason.

    Thanks,
    Karl

    P.S. hofman: the intent is that the .synctex file is indeed written in the -output-directory. it is for me. not doing so would be a separate bug (and possibly not Jerome's).

     

Get latest updates about Open Source Projects, Conferences and News.

Sign Up No, Thank you