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.

mike
  • 479
  • 1
  • 7
  • 14
  • 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 '13 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 '13 at 16:13
  • 2
    See http://tex.stackexchange.com/q/2006/5763 – Martin Schröder May 28 '13 at 09:24

5 Answers5

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.

Pontis
  • 103
  • 3
Mattias
  • 601
  • 6
  • 11
  • 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 '13 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 Jun 27 '23 at 18:43
3

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

isti_spl
  • 139
  • 3
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
mpy
  • 27,002
  • 7
  • 85
  • 97
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

K J
  • 335
  • 7