<div>Feeding `latex` with<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>\documentclass[a4paper]{article}<br>\begin{document}<br>Test<br>\end{document}<br></div><div><br data-mce-bogus="1"></div><div>or<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>\documentclass{article}<br>\setlength\paperheight{297mm}%<br>\setlength\paperwidth{210mm}<br>\begin{document}<br>Test<br>\end{document}<br></div><div><br data-mce-bogus="1"></div><div>and running `dvips` on the resulting DVI file yields the following lines (among many others) in the PostScript file:<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>%%BoundingBox: 0 0 596 842<br>%%DocumentPaperSizes: a4</div><div>%%BeginPaperSize: a4</div><div>{ pop << /PageSize [595 842] >> setpagedevice }<br>{ /a4 where { pop a4 } if }</div><div><br data-mce-bogus="1"></div><div>inside mwe.ps. The contents of the document does not touch any margins; it's pointless and confusing to have the bounding box wider than the paper (596 pt > 595 pt).</div><div><br data-mce-bogus="1"></div><div>Apparently, 596 is computed in the following function of output.c of dvips:<br data-mce-bogus="1"></div><div><pre>/*
 *   Convert scaled points to PostScript points.  This is the same
 *   as return (i * 72 / (65536 * 72.27)), which is the same as
 *   dividing by 65781.76, but we want to round up.
 */
static int
topoints(integer i)
{
   i += 65780L;
   return (i / 6578176L)*100 + (i % 6578176) * 100 / 6578176;
}</pre><div>This has two big issues:<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>• Why rounding UP (and not in some other way, e.g., towards the nearest integer; also cf. <a href="https://en.wikipedia.org/wiki/Rounding">https://en.wikipedia.org/wiki/Rounding</a> )? The function comment provides us with no rationale here, but it should. (E.g., you can claim that you don't wish to clip hypothetically drawn stuff away. However, it's a weak argument; a counterargument would be that you also don't wish to invent a whole 1-pt-wide column or 1-pt-high row out of nowhere. Further, if the paper were later really cut (e.g., by a high-end printer) according to BoundingBox rather than PageSize, the paper wouldn't fit into the real-world tight enclosures for A4. In my view so far, rounding towards the nearest integer would be more natural.)<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>• The code does NOT always compute ⌈i÷65781.76⌉, where ÷ is mathematical division. This can be witnessed already by i=1: the code yields (65781/6578176)·100 + (65781%6578176)·100/6578176 = 0·100 + 65781·100/6578176 = 0 + 6578100/6578176 = 0 (where `/` and `%` are the division and remainder on the type `integer` (int or long) in C), whereas it should yield ⌈1÷65781.76⌉ = 1. If anyone wishes to round up after all, here's how to do it without risking an overflow: <a href="http://stackoverflow.com/a/78127921">http://stackoverflow.com/a/78127921</a>. For rounding towards the nearest integer, use, e.g., `return (25LL*i+822272)/1644544;` and C99 (there might be an overflow-free and portable variant thereof; I have not tried).<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>Kudos go to David in <a href="http://tex.stackexchange.com/a/712493">http://tex.stackexchange.com/a/712493</a> ; many thanks!<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>So three items need to be fixed:<br data-mce-bogus="1"></div><div>(1) BoundingBox should probably stay within the paper size. If really nothing is drawn outside the paper, BoundingBox should definitely stay within the paper.<br data-mce-bogus="1"></div><div>(2) The kind of rounding should be critically reevaluated and probably changed.<br data-mce-bogus="1"></div><div>(3) The C code should actually implement the chosen rounding.<br data-mce-bogus="1"></div><div><br data-mce-bogus="1"></div><div>Gratefully,<br data-mce-bogus="1"></div><div>AlMa<br data-mce-bogus="1"></div></div>