<div>Thank you, Karl!<br></div><div><br data-mce-bogus="1"></div><div>I correct myself at one more place: <a href="http://stackoverflow.com/a/78127921">http://stackoverflow.com/a/78127921</a> is an overflow-free version rounding down (viz., computing ⌊integer 𝑥 ÷ 65781.76⌋), whereas the comment before topoints() in <a href="https://tug.org/svn/texlive/trunk/Build/source/texk/dvipsk/output.c?revision=61701&view=markup">https://tug.org/svn/texlive/trunk/Build/source/texk/dvipsk/output.c?revision=61701&view=markup</a> implies that the function wants to round up (viz., to compute ⌈integer 𝑖 ÷ 65781.76⌉). So please ignore the stackexchange link unless someone decides that rounding down is necessary. As for computing ⌈integer 𝑖 ÷ 65781.76⌉ precisely in C89/C90, a clear attempt would be ⌈25𝑖 ÷1644544⌉=⌊(25𝑖+1644543)÷1644544⌋. Its overflow-free encoding in C is `static int topoints(integer i) {return (i/128 + i/256 + i/2048 + 802 + (i % 128 * 16 + i % 256 * 8 + i % 2048 + 2047)/2048) / 803;}` (double-check this). By the way, I don't understand why `integer` and not `uinteger` is used here; can the variables storing paper width or height be negative? If not, consider using `uniteger` throughout and saying `static unsigned topoints(uinteger i) {return (i/128U + i/256U + i/2048U + 802 + (i % 128U * 16U + i % 256U * 8U + i % 2048U + 2047U)/2048U) / 803U;}`?<br></div><div><br data-mce-bogus="1"></div><div>As for the getting the width of BoundingBox right: If what you wrote is the rationale for rounding UP (and having 596 instead of the usual 595), this rationale should be documented somewhere.  At the same time, the user might expect the same bounding-box width as the paper width, whichever they happen to be.<br></div>