Inconsistent error message among drivers

[yudai-nkt]

Please consider the following MWE (note that nil.pdf should not exist).

\ifnum\pdfoutput=0
  \PassOptionsToPackage{dvipdfmx}{graphicx}
\fi
\documentclass{article}
\usepackage{graphicx}
\begin{document}
\includegraphics{nil.pdf}
\end{document}

When you typeset this MWE with pdflatex, you will get an error saying ! Package pdftex.def Error: File `nil.pdf' not found: using draft setting. This explains the exact reason of the error.

This is not the case for LaTeX + dvipdfmx. When you typeset with latex, the error message is ! LaTeX Error: Cannot determine size of graphic in nil.xbb (no BoundingBox). This is somewhat confusing because extractbb is listed in shell_escape_commands in reasonably new TeX Live and BoundingBox info should be available. The reason is that LaTeX cannot find nil.pdf, and LaTeX and extractbb claims so in the log. However, both messages are warnings.

I'd be happy if the error message, which is likely to be the first message users will check, could be more appropriate and precise like the one in pdftex.def. IMHO, graphicx should issue an error as soon as it notices that the included file does not exist regardless of the driver in use. Would this be possible?

Notable situation where users encounter this kind of error would be when they made a typo in file name (and I actually did).

[davidcarlisle]

We can look at this again, but perhaps I can mention the reason for the split between warnings and errors.

Originally the model was that you got an error if the file size was not supplied in arguments, or could not be determined from a .bb file or similar. But you only got a warning if the actual graphic was not present (because classically TeX didn't need it, and it wasn't needed until the dvi file was printed, which may not even be on the same machine).

At that time it was I think fairly clear to the user which state they were in.

Of course these days the distinction between the latex macro layer just needing size information and the back end just needing the image is less clear, first with pdftex that does both stages, and then with "hidden" calls to extractbb and similar which means that the image file is almost always the source of the size information. however with your test file the terminal output is

LaTeX Warning: File `nil.pdf' not found on input line 7.


extractbb:warning: Can't find file (nil.pdf), or it is forbidden to read ...skipping


! LaTeX Error: Cannot determine size of graphic in nil.xbb (no BoundingBox).

which isn't entirely unreasonable. First latex gives a warning that the pdf isn't there (that's just a warning because latex doesn't need the pdf). Then it tries to determine the size using extractbb, that gets an error.
I suppose it would be nice to detect that error case and flag that as an error at that point, we can look at that, but may be tricky to do that cross platform, I'm not sure the error status and message are returned in a reliable way, so extractbb has failed and there is no xbb file. Then finally, at that point you get an error that latex can not find the file size because there is no(x)bb file.

[FrankMittelbach]

Would it help if the actual error line would state something like "look at earlier LaTeX warnings to determine the exact reason"?

[davidcarlisle]

On 12 January 2018 at 09:43, Frank Mittelbach ***@***.***> wrote: Would it help if the actual error line would state something like "look at earlier LaTeX warnings to determine the exact reason"?

It would, except that I now see that the exact reason (failure of the extractbb script) is _only_ in the terminal output (which many users using IDE do not see) it isn't captured by the log. I'm not sure I can grab STDERR from an external process in a reliable cross platform way...

[yudai-nkt]

that's just a warning because latex doesn't need the pdf

This is very persuasive and I now understand why LaTeX treats this as a warning rather than an error, thanks.

I said graphicx should issue an error, but it doesn't seem really correct. That being said, I agree that the image file itself is usually the source of the size information these days.

Would it help if the actual error line would state something like "look at earlier LaTeX warnings to determine the exact reason"?

It will, especially if rigorous and cross-platform detection can be a tricky/dirty implementation. It turns out to be more complicated than I initially thought...

[davidcarlisle]

One thing that we should be able to do is not try to call extractbb if we have just detected that the pdf file is not there. That would mean that the most common cause of extractbb failing would never arise and so we can probably give a better worded error message in that case.