The possibility of postprocessing mentioned in the latexmk documentation is only for dvi and postscript files. (See the description of the -dF
and -pF
options, and of the configuration variables $dvi_filter
and $ps_filter
.) I need to correct the documentation on this point. I could improve latexmk to also do this for pdf files.
But there is a simpler and more general method. Just define the $pdflatex
command to include the invocation of qpdf. For example, you could put the following in one of latexmk's initialization files:
$pdflatex = 'pdflatex %O %S && qpdf -linearize %D tmp.pdf && mv tmp.pdf %D';
(This is in a form suitable for Unix-like operating systems, it will need to be changed for MS-Windows, probably.) When latexmk uses this, it executes the pdflatex command; if successful it invokes qpdf, putting the result in a temporary file; if that is successful the temporary file is moved to replace the originally generated pdf file.
I don't have qpdf installed on my computer, so I am working from its documentation to write a suitable invocation of it.
If you want a command line option to control the use of qpdf, put the above line in its own file, e.g., useqpdf. Then you can invoke latexmk to read this file when needed:
latexmk -r useqpdf foo.tex
Best Answer
(As the author of
latexmk
, I am naturally partial to my own program, but here's my 2-cents' worth anyway.)The fundamental problem that
latexmk
solves is that the number of runs of(pdf)latex
needed is highly dynamically dependent on the document and the class file used. If you make a small change to a document, often only one recompilation by(pdf)latex
is needed, but not always. But some cases consistently need at least 4 runs. So running a fixed sequence of programs is definitely non-optimal.Latexmk
is designed to perform the right number of runs of the programs involved as reliably as possible while only using a small amount of resources compared with the called programs; most of the running time goes to(pdf)latex
under normal situations.The method it uses is to determine the set of all input files and to efficiently test for changes in content since the last run. If the content of an input file has changed, a new compilation is made. For normal documents, this process works correctly.
One other advantage of
latexmk
is that if your document includes graphics files that need to be converted from the native form for the graphics editor (e.g., xfig), thenlatexmk
can be configured do an automatic conversion to the format needed for(pdf)latex
, e.g., .pdf or .eps. For a human, it's one more mechanical step that's easy to forget occasionally, especially in documents with tens or hundreds of graphical elements.The only regular case I know where
latexmk
consistently does an extra run, is that in the case mentioned by the OP,latexmk
does an extra run ofbibtex
between the second and third runs ofpdflatex
. It does this because the .aux file changed after the second run ofpdflatex
, andlatexmk
does not know that the particular changes that occurred do not actually matter tobibtex
's output. The extra time for thebibtex
run is small enough that it hasn't seemed worthwhile to do extra testing to optimize it.As for when
latexmk
fails do enough runs, the cases I know of are when compilation of a document runs external programs orluatex
code to process external files. In these cases,latexmk
doesn't normally know about the external files because the file names aren't reported by the running compilation, although that can be fixed. However, for most people creating LaTeX documents this situation doesn't occur.