25

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.

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
    Commented 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
    Commented May 24, 2013 at 16:13
  • 2
    See tex.stackexchange.com/q/2006/5763 Commented May 28, 2013 at 9:24

5 Answers 5

20

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

2
  • 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
    Commented May 24, 2013 at 17:17
  • Another benefit of SumatraPDF: it keeps the view for page and zoom after reloading (which is nice if using other tools than LaTeX to modify the PDF).
    – Pontis
    Commented Jun 27, 2023 at 18:43
3

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

2
  • 2
    Can you add more detail to your answer? Saying "X does the job" is too vague to be helpful. Thanks for contributing. Commented 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. Commented 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
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.)

0

Both Main Distros of TeX include a native Editor Viewer combination that naturally does not lock the file against its own edits.

When you run Windows tl-tray-menu.exe you will see the Editor Option enter image description here
A similar Editor with PDFsync-hronised TeXworks Viewer is included with MiKTeX enter image description here

If you simply give the TeXworks.exe a PDF file it will open that first and only open the editor as requested by Reverse (Inverse) Search

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .