24

I'm working on a latex document (with pdflatex, cygwin, acrobat reader) and I'm am tired of the make - close - open process.

On osx with Preview I don't have that problem, since I can compile the .tex files, while the resulting pdf is opened in the viewer (which gets updated after the build process).

Whereas on Win7, with Acrobat Reader, my pdflatex (tex-live 2012) complains that it [...] can't write on file xxx.pdf. I guess the reader locks the pdf file.

How do you efficiently produce/edit .tex files on Win7? I preferably would stick to using makefiles and a text editor instead of a windows latex build environment.

Improve this question
3
  • If that is an option for you: I think (can't check it right now) xpdf via cygwin works that way. However you need to turn the page forth and back in order to update the displayed file.
    – mpy
    May 24, 2013 at 15:54
  • Thx, it's good for starters. But since I know how it's handled on the mac, I'd be glad to have some other solutions.
    – mike
    May 24, 2013 at 16:13
  • 2
    See tex.stackexchange.com/q/2006/5763
    – Martin Schröder
    May 28, 2013 at 9:24

4 Answers 4

Reset to default
19

SumatraPDF can be used in your current workflow. It will not place a lock on the file. It also supports synchronization between editor and pdf document.

Improve this answer
1
  • 1
    I wanted to post the same a minute ago, but I couldn't answer my own question with less than 10 rep... :) Anyway, thank you!
    – mike
    May 24, 2013 at 17:17
3

As of 2017 also Firefox/Chrome can do the job. Firefox even keeps the current page after F5 - Refresh.

Improve this answer
2
  • 2
    Can you add more detail to your answer? Saying "X does the job" is too vague to be helpful. Thanks for contributing.
    – I say Reinstate Monica
    Sep 27, 2017 at 14:25
  • 1
    Web browsers in general should work. The default/normal/expected behavior for REST clients is to load the content of a URL and then close the connection.
    – StackOverthrow
    Feb 1, 2019 at 22:01
2

Although there's already an answer providing a native non-blocking windows PDF reader, I followed the cygwin/xpdf approach and hacked together a small script.

It is based on xpdf's -remote option which which it is possible to reload an already opened file. So, we only need to detect when the file is changed. As there is no native inotify on windows you need to install inotify-win, which is a C# program.

My script xpdf-f seems to work fine, however you have to close both, xpdf and the the script (via Strg+C) once finished watching the PDF.

#!/bin/bash

if [[ "$1" = "" ]]; then
  echo Usage: $0 FILE
  exit 1
fi

if [[ ! -e "$1" ]]; then
  echo Error: File $1 does not exist.
  exit 2
fi

xpdf -remote filewatch "$1" &
XPDFPID=$!

while [[ -e /proc/$XPDFPID ]]; do
  inotifywait `dirname $1` | grep "MODIFY $1"
  [[ $? = 0 ]] && xpdf -remote filewatch -reload
done
Improve this answer
0

It appears that Chrome does not quite do the same thing as the PDF viewer under linux.

Although chrome doesn't lock the file, it seems to open the file again every time it is modified. (Displaying it from the beginning in a new TAB.)

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.