[Tex/LaTex] latexmk -pvc option breaks when compiling beamer class

Question

latexmk is the tool I'm using to compile my documents, and the -pvc option is the one which is normally on. In this setting, when I save a file which produces a compilation error, then latexmk informs that there was an error and the document is not being updated in the viewer (skim in my case). Once I correct the problem in the .tex file, latexmk kicks in again, and resumes its activity. In particular, the open document is refreshed correctly.

Problem occurred to me, when I use the setting mentioned above, when trying to compile a beamer's class document (and if it makes any difference, using the beamerposter package). In this case, when compiling a file with a mistake in it, then latexmk will report the problem and the document won't update as before. However, once I correct the problem in the source, latexmk recompiles, and produces the correct .pdf file, but the link to the open document breaks, and I have to reopen it manually… In other words, the document which was open, is dead and doesn't "see" the updated version which was created after the correction of the mistake.

Do you have any idea how to handle this? Where to look for a solution?

Edit:

I have just realized that the same problem happens also when compiling sources not using beamer. The cause this time might be the tikz graphics. Any ideas?

Edit 2 – Possible way out:

Skim offers the revert option, which seems to fix the broken linkage between skim and the damaged/badly-processed pdf. Can you think of a way to turn this clue into a full solution?

Answer 1

The problem is not specific for latexmk, but related to Skim, the way pdflatex works and how file notifications are implemented in OSX (and its Mach kernel under the hood).

• The problem is that pdflatex does not change the PDF file in an atomic manner, but during the compilation process more or less continuously updates bits and bytes inside it.

• The file system notices the writes to the file and sends an update notification to the monitoring Skim process. It uses some heuristics to not send an update event for every single changed byte (which would be very inefficient). The common approach here is to delay the update notification until no new changes have shown up for some time (usually a couple of milliseconds).

• If this heuristic interacts badly with the write pattern of pdflatex, Skim gets notified before the PDF is ready and tries to read a not-yet complete PDF file. However, Skim is not well prepared for this, which result in all sorts of problems: from strange error messages over crashes to a lost of the notification handle. The last is the behaviour you observe.

• The problem should not per se be bound to specific document classes, such as beamer. However, I also observed it especially in conjunction with beamer. My assumption is that when compiling beamer documents, pdflatex has usually to generate a whole extra bunch of files (all that .toc, .vrb, .nav, .snm files) and in between also spends relatively much computing time. As a result, updates to the PDF file during compilation are less frequent, which increases the probability of a bad interaction with the file system's heuristic to send change notifiations.

My personal solution to the problem is to add another level of indirection: Whenever the command to build the final PDF (I use pdflatex directly or rubber) has terminated successfully, I copy the resulting document.pdf to a document-view.pdf, which is the file I have open in Skim. The copying happens more or less instantaneous, the update mechanism works fine.

I personally use a Makefile for this task in combination with a small Ruby script that observes the source files to invoke make whenever a source file has changed. To integrate such behavior into latexmk one probably has to hack a bit around with the tool settings in latexmkrc (e.g., setting $pdf_previewer='cp %S %S-view.pdf'). However, my experience with latexmk is limited and I have not tested this.