Comment 9 for bug 882167

I've spoken with Tom Rokicki, author and maintainer of epsf.tex.

The EPSF spec defines the bounding box:

%%BoundingBox: llx lly urx ury

"The four arguments of the bounding box comment correspond to the lower- left (llx, lly) and upper-right (urx, ury) corners of the bounding box. They are expressed in the default PostScript coordinate system. For an EPS file, the bounding box is the smallest rectangle that encloses all the marks painted on the single page of the EPS file. Graphics state information, such as the current line width and line join parameters, must be considered when calcu- lating the bounding box. Example 1: shows a minimally conforming EPS file that draws a square with a line width of 10 units."

A bounding box of "%%BoundingBox: 0 -2147483648 0 -2147483648" is a negative-space box, and cannot be printed or included in a file as a result. You might have noticed that 2147483648 is 0x80000000, and I wonder if what we're seeing is truncation, rounding error, or overflow.

Tom made the case to me that such "broken" .eps files should not be properly handled, though he is willing to continue the discussion should I present a compelling case.

I myself cannot really present a compelling case for what a negative-space box is, other than a software error. It seems I should escalate this problem to the cairo team, though my only test case is unfortunately inkscape, and I do have some confusion over the difference between what we're seeing on the command-line vs what we're seeing from the GUI.

Do you think the 2147483648 value is being set by inkscape, and therefor the bug is in how inkscape is using cairo, or is this in fact a bug in cairo that inkscape has nothing to do with?