<div dir="ltr">I did notice that code, but I think I prefer the less opaque version:<div><br></div><div>   ceil(i * a / b) = i / b * a + (i % b * a + b - 1) / b</div><div><br></div><div>which is also overflow-free given our current values of a and b.</div><div><br></div><div>Do you disagree?</div><div><br></div><div>-tom</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Mar 10, 2024 at 7:12 PM Al Ma <<a href="mailto:alma0@ro.ru">alma0@ro.ru</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>Tom, thank you for your quick reply. I see. By the way, I know too little to further comment on what was noticed by Zdeněk, Karl, or Reinhard than I've already written to the tex-live list, so please don't listen only to my words.<br></div><div><br></div><div>If you end up going for rounding up, viz., ⌈integer 𝑖 ÷ 65781.76⌉, as the current code in ouput.c has some small chance to overflow when adding, and you probably would not like to make it worse by introducing a multiplication by 25 (the users of dvips cannot be underestimated), please consider an overflow-free code. I double-checked my own suggestion from <a href="https://tug.org/pipermail/tex-live/2024-March/050188.html" target="_blank">https://tug.org/pipermail/tex-live/2024-March/050188.html</a> for nonnegative 𝑖 and then inserted one forgotten U for the case of unsigned numerical literals (viz., `(i/128U + i/256U + i/2048U + 802U + (i % 128U * 16U + i % 256U * 8U + i % 2048U + 2047U) / 2048U) / 803U`) and successfully tested this for all 𝑖 between 0 and INT32_MAX. For negative i and pre-C99, probably something else should be done anyway (fail with an error message?) because of this para in the draft of the spec of ANSI C: “When integers are divided and the division is inexact, if both operands are positive […].  If either operand is negative, whether the result of the / operator is the largest integer less than the algebraic quotient or the smallest integer greater than the algebraic quotient is IMPLEMENTATION-DEFINED, as is the sign of the result of the % operator.  […]” (The emphasis is mine.)<br></div><div><br></div><blockquote><div>10.03.2024, 23:11, Tomas Rokicki <<a href="mailto:rokicki@gmail.com" rel="noopener" target="_blank">rokicki@gmail.com</a>></div><div id="m_7776813218561843483part2"><div><div><div dir="ltr">The bounding box comment does correlate with, but does not indicate, the paper size.<div><br></div><div>The paper size is specified by the %%DocumentPaperSizes: DSC comment (and I believe for dvips it will only ever list</div><div>a single paper size).</div><div><br></div><div>The %%BoundingBox comment on a multi-page document has (as far as I know) no reasonable meaning or</div><div>interpretation.  The original Document Structuring Conventions issued by Adobe declared that it should contain</div><div>the smallest box (in integer big points) that fully encloses all marks made on all pages, but their very first example</div><div>of 0 0 612 792 belies this as that's not a reasonable value.  (If the pages truly are intended to bleed, this box</div><div>should be larger by at least a couple of points in each dimension; if the pages don't bleed, it should be smaller</div><div>by some reasonable margin).</div><div><br></div><div>But following this example, way back in the 80's, I made the dvips bounding box be a "rounded up" version of</div><div>the paper size.  The paper size itself can be specified in a special, and the user can use whatever units and</div><div>rounding in that specification they desire, so a certain amount of slop is unavoidable.  This is why dvips allows a</div><div>certain amount of slop when matching media sizes.</div><div><br></div><div>Now, the code clearly doesn't do precisely what the comment says it does, and this is a problem, and will be fixed,</div><div>either by changing the comment or the code; it is not clear which.  But I don't want to change the behavior if I can</div><div>avoid it.  For EPSF file generation it's critical that the bounding box be rounded *up* (or a hi res bounding box</div><div>provided, but I'm not sure that ever got fully blessed by Adobe and/or what software might support it).  So I'm</div><div>tempted to maintain the rounding up behavior.  And 210mm rounds *up* to 596 bp, so that number will stay.</div><div><br></div><div>The current code does not always round up, but if it ever rounds down it will round down only by less than a</div><div>millionth of an inch, which is unlikely to be discerned by a casual viewer.  And the bounding box should *not*</div><div>be used as a clip box except in very specific uses.</div><div><br></div><div>If people are using the values in the bounding box and comparing them against (say) ISO 216 paper sizes and</div><div>expecting an exact match, they may be disappointed.  But I see no reason they should match.  If anyone does,</div><div>and can point me to a specification and use case for a multipage bounding box, I may reconsider.</div><div><br></div><div>So I think we'll likely improve the rounding in the code to round up using exact integer arithmetic (using a simple</div><div>approach for clarity), but there's no rush to make that happen.  The chances of that changing the dvips output</div><div>bounding box for practically any real-world document is pretty negligible, so we'll do it just to polish the internal</div><div>code a tiny bit.</div><div><br></div><div>-tom</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Mar 10, 2024 at 2:28 PM Al Ma <<a href="http:///compose" rel="noopener" target="_blank">alma0@ro.ru</a>> wrote:<br></div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><div id="m_7776813218561843483m_3022986450385439039part2"><div><div><div>> What is the practical problem …?<br></div><div><br></div><div>@Tom Thank you for a reply.<br></div><div><br></div><div>The partical problem I ran into is this: While looking at a 15-year-old real-world Postscript file that specified a BoundingBox but had a wrong orientation (relative to the content) and an unclear paper size (relative to the country; I recall having deduced “letter”), I started wondering why and which size could be intended. I looked at what BoundingBox specified and found no standard paper size with 596 pt.<br></div><div><br></div><div>A bug report that, although with a subjectively low chance, might be related is <a rel="noopener" href="http://bugs.debian.org/1036115" target="_blank">http://bugs.debian.org/1036115</a> .<br></div><div><br></div><div>Beyond that, I am driven by curiosity.</div><div><br></div><div>A general rule of software development is: a combination of code and its specification (here: a comment) that don't match should be repaired (by repairing the code or the spec or both) or removed.<br></div><div><br></div><div>Finally, David suggested in<br></div><div><br></div><div><a rel="noopener" href="https://tex.stackexchange.com/questions/712490/why-does-running-latex-with-a4paper-or-210-mm-%c3%97-297-mm-followed-by-dvips-result#comment1770964_712493" target="_blank">https://tex.stackexchange.com/questions/712490/why-does-running-latex-with-a4paper-or-210-mm-%c3%97-297-mm-followed-by-dvips-result#comment1770964_712493</a><br></div><div><br></div><div>that I submit a bug at tex-live, so I did.<br></div><div><br></div><div>@Karl Alright, posting to tex-k instead of tex-live.<br></div></div><br></div></div></blockquote></div><br><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>-  <a rel="noopener" href="http://cube20.org/" target="_blank">https://cube20.org/</a>  -  <a rel="noopener" href="http://golly.sf.net/" target="_blank">https://golly.sf.net/</a>  - <a rel="noopener" href="https://alpha.twizzle.net/" target="_blank">https://alpha.twizzle.net/</a><br></div><div>/ -</div></div></div></div></div></div><br></div></div></blockquote></blockquote></div><br clear="all"><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>-  <a href="http://cube20.org/" target="_blank">https://cube20.org/</a>  -  <a href="http://golly.sf.net/" target="_blank">https://golly.sf.net/</a>  - <a href="https://alpha.twizzle.net/" target="_blank">https://alpha.twizzle.net/</a></div><div>/ -</div></div></div></div></div>