The possibility of postprocessing mentioned in the latexmk documentation is only for dvi and postscript files. (See the description of the
-pF options, and of the configuration variables
$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
(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
latexmksolves is that the number of runs of
(pdf)latexneeded 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)latexis needed, but not always. But some cases consistently need at least 4 runs. So running a fixed sequence of programs is definitely non-optimal.
Latexmkis 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)latexunder 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
latexmkis that if your document includes graphics files that need to be converted from the native form for the graphics editor (e.g., xfig), then
latexmkcan 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
latexmkconsistently does an extra run, is that in the case mentioned by the OP,
latexmkdoes an extra run of
bibtexbetween the second and third runs of
pdflatex. It does this because the .aux file changed after the second run of
latexmkdoes not know that the particular changes that occurred do not actually matter to
bibtex's output. The extra time for the
bibtexrun is small enough that it hasn't seemed worthwhile to do extra testing to optimize it.
As for when
latexmkfails do enough runs, the cases I know of are when compilation of a document runs external programs or
luatexcode to process external files. In these cases,
latexmkdoesn'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.