I have numerous individual files that need to be compiled, so am using a script to do that with the following options:

set PDFLATEX_OPTIONS = "        --file-line-error         --shell-escape         --synctex=1         --interaction=nonstopmode         --recorder "

as I don't want compilation to terminate just because there is an error in one file.


I would like my script to detect which files totally failed to produce useful results. At this time, I am not too concerned with slight overfull/underfull box reports, but trying to focus on the ones that must be fixed (as opposed those that should be fixed).

For conditions that are specific to my own use case, I have put as much error detection as possible and write to the log file very specific error messages which my script can detect and report any problems. This process has worked great until I recently came across an issue where some PDF files were not produced at all due to a change in my common .sty files. Well, that was an easy fix, I just use:

grep "no output PDF file produced"

and test the return code to detect this failure. But this got me thinking, which is always a bad sign :-), that perhaps there might be some case where that message is not generated, but the PDF file does not contain any content, or there are other catastrophic failures that can occur.


What I am looking for are recommendations on specific error messages to look for in the log files, or automate-able tests that should be performed to minimize the chance of a some extremely important failure being overlooked.

And even tough I am mainly concerned with what must be fixed, at some point I will need to look at the should be fixed category also. For example, at some point an overfull box warning is really a must be fixed. Any suggestions on these would also be useful.


  • Perhaps I should just be looking at the return code from pdflatex instead of specific error messages, but I think it would be more useful to be able to categorize the failures so that I can prioritize.
  • This question isn't about things that can be detected via the nag package for instance as discussed in

    I am using as much of that kind of detection that I am aware of, and I review the PDF file at the time of creation to make sure it looks reasonable, but can't be looking at every PDF every time I change the .sty files.


  • 2
    I don't think pdflatex returns useful error codes apart from 0 and 1. However you're contradicting yourself: you give the -halt-on-error and say you don't want to stop just because of an error.
    – egreg
    Jul 5, 2013 at 19:54
  • @egreg: :-) I guess since it did what I wanted I didn't look at the options carefully enough. Have corrected. Jul 5, 2013 at 22:46
  • I'm somewhat confused. You seem to be talking about both errors and warnings within a single category. But surely one important category of information is provided precisely by the fact that something is an error rather than a warning or vice-versa. That said, something which shows up as 'merely' an overfull box can, in some cases, mean a completely empty PDF. (I didn't know this was possible until a couple of days ago.)
    – cfr
    Jul 31, 2015 at 23:48
  • Have you looked at texfot? It is designed to run TeX, filtering online transcript for interesting messages (from the man page). This might make it easier to grep effectively by reducing the initial size of output to be filtered.
    – cfr
    Aug 1, 2015 at 2:47
  • @cfr: Did not know about overfull boo resulting in an empty PDF. Do you have a reference for that? Never heard of texfot, but does look interesting. Will have to try it out. Aug 1, 2015 at 5:16

1 Answer 1


that perhaps there might be some case where that message is not generated, but the PDF file does not contain any content, or there are other catastrophic failures that can occur.

This document doesn't produce any error or "no output PDF produced" warning but may be considered as perhaps an error that should be fixed. It may or may not be a case of the situation you describe depending how you define "no content"....



hello, this important message must be typeset

  • Good example. So, how would I go about automating the detection of such failures via a script? This was obviously intentional, but am conceded that there might be some cases where I get this behavior, but is not obvious. Jul 31, 2015 at 19:24
  • @PeterGrill er well it's hard, that one really is in the same category as a spelling error: incorrect input makes a technically complete pdf with unintended contents. I just answered to answer the question about what can go wrong rather than say what to do about it. you could for example use the pdffonts utility on the pdf which will return an empty list which you could check for, but it's diminishing returns really. Jul 31, 2015 at 20:20

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .