RE: BoundingBox in PostScript output for A4 is too large and the co mputation with its comment are bogus

[Al Ma]

Thank you, Karl!
I correct myself at one more place: http://stackoverflow.com/a/78127921 http://stackoverflow.com/a/78127921 is an overflow-free version rounding down (viz., computing ⌊integer 𝑥 ÷ 65781.76⌋), whereas the comment before topoints() in 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 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;}`?
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://tug.org/pipermail/tex-live/attachments/20240310/055dfc31/attachment-0001.htm>