Take the 2-minute tour ×
TeX - LaTeX Stack Exchange is a question and answer site for users of TeX, LaTeX, ConTeXt, and related typesetting systems. It's 100% free, no registration required.

My source file is based on the standalone package. The \documentclass command specifically looks like this:

\documentclass[preview, convert={density=300}]{standalone}

If the source file is named main.tex, compiling it will result in producing the main.pdf and main.png files.

latexmk runs only once the first time main.png is created. However, it goes into an endless loop once I begin updating the source file (and hence the main.pdf and main.png)

I think this is because latexmk mistakes the main.png file as part of the source for building the final main.pdf.

Is there a way to exclude certain files from being monitored by latexmk? I searched inside man latexmk but there are no occurrences of "exclude".

share|improve this question
    
At present there is no simple way to exclude files from being monitored. But this example shows that this would sometimes be a useful feature. (Note that in the .fls file produced by pdflatex in the example, the main.png file is listed as an input file. So it is natural for latexmk to deduce that main.png is a genuine source file.) I've added the possibility of configuring latexmk to exclude specified files from being monitored to my list of proposed future improvements for latexmk. –  John Collins Nov 27 '12 at 19:07

2 Answers 2

I can reproduce this with latexmk 4.35. The issue is that the created png file contains date+time created meta-information which changes on every run, and latexmk thinks the png file is part of the input, not output. I cannot think of an appropriate regular expression for $hash_calc_ignore_pattern{'png'} to really solve this at the right level since pngs are binary files.

However, I can help you to get latexmk to ignore the generated png file. The reason why latexmk thinks the png file is an input to your document is that in standalone.cls, there are commands like \IfFileExists{\outfile with various forms of file extensions to detect if conversion succeeded. Therefore, as far as pdflatex knows, you are reading that file during the run, but it knows nothing about you writing the file as it is done externally to the TeX engine. This information that pdflatex has is picked up by latexmk through the recorder feature. Disabling the recorder feature (by adding -recorder- to the latexmk options) means latexmk becomes ignorant of the png file and cannot therefore rerun when it changes. I am not aware of any feature in latexmk that allows you to specify an 'ignore dependants' list within which you could specifically name the output png file.

Also, from the standalone manual:

standalone executes the same LaTeX compiler (e.g. pdflatex) again as a sub-process which compiles the current document fully. This is done when the standalone class is loaded, so that the main compiler instance is still at \documentclass and has not yet itself opened the output file for writing. After the document got compiled using the sub-process the external conversion tool will be executed. If required intermediate conversions like dvips are also executed beforehand. Finally the main compiler run is terminated without producing any output, keeping the output file generated by the sub-process intact. A drawback of this implementation is that the log file created by the sub-process is overwritten by the main process and does not hold meaningful information. This can be compensated by setting a different jobname for the sub-process using the subjobname conversion setting.

Note this refers to running pdflatex on the subjob, not latexmk! As latexmk is reliant on the information in the log file, we should follow the suggestion of using a different jobname for the sub-process.

There are therefore two steps which together seem to workaround the problem at this stage:

  • Use the subname option to the convert settings in standalone.
  • Pass the -recorder- option to latexmk to disable the recorder feature of pdflatex (so the generated png file is not identified as a dependant).

MWE (called converttest.tex for the command line given below):

\documentclass[preview, convert={density=300,subjobname=\jobname-converted}]{standalone}
\begin{document}
    Hello.
\end{document}

latexmk command line: latexmk -pdf -shell-escape -recorder- "converttest"

Then, change the TeX file, perhaps changing Hello to Hello world and re-run the same latexmk command-line. Things work if -recorder- is used but not otherwise. But now remember that the output image has a different filename (-converted is appended).

share|improve this answer

The solution using a different subjobname works, at least in the simplest cases. But by not using the recorder option, it doesn't give latexmk full knowledge about the dependent files. Also the actual desired output .png file is not produced by a run of pdflatex that is directly controlled by latexmk, so latexmk will could have misleading dependency information: E.g., it will not know the actual .aux files used by the run of pdflatex producing the .png file.

The arrangement used in the original example is that the standalone package does a subsidiary run of pdflatex with a special command line, and then it runs a program to convert the .pdf file to a .png file. An alternative arrangement is to give all that work to latexmk with a suitable configuration. I have a latexmkrc file with the following contents:

$pdf_mode = 1;
$dvi_mode = $postscript_mode = 0;
$pdflatex =
   'pdflatex %O'.
      '"\\expandafter\\def\\csname sa@internal@rune\\endcsname{1}\\input{"%S"}"; '.
   'convert -density 300 %D -quality 90 %R.png';

and a document file

\documentclass[preview]{standalone}
\begin{document}
\begin{equation}
   \label{eq:Emc2}
   E=mc^2.
\end{equation}
See (\ref{eq:Emc2}).
\end{document}

Just running latexmk on the document file gives the desired result. No extra options are needed.

Note that the configured command line for pdflatex has quoting that works on UNIX-like systems (e.g., OS-X, where I've tested it, and presumably linux). It will need some changes for MS-Windows.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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