[tex-k] dvips bounding box

Mon Mar 11 05:34:51 CET 2024

I did notice that code, but I think I prefer the less opaque version:

   ceil(i * a / b) = i / b * a + (i % b * a + b - 1) / b

which is also overflow-free given our current values of a and b.

Do you disagree?

-tom

On Sun, Mar 10, 2024 at 7:12 PM Al Ma <alma0 at ro.ru> wrote:

> 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.
>
> 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
> https://tug.org/pipermail/tex-live/2024-March/050188.html 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.)
>
> 10.03.2024, 23:11, Tomas Rokicki <rokicki at gmail.com>
> The bounding box comment does correlate with, but does not indicate, the
> paper size.
>
> The paper size is specified by the %%DocumentPaperSizes: DSC comment (and
> I believe for dvips it will only ever list
> a single paper size).
>
> The %%BoundingBox comment on a multi-page document has (as far as I know)
> no reasonable meaning or
> interpretation.  The original Document Structuring Conventions issued by
> Adobe declared that it should contain
> the smallest box (in integer big points) that fully encloses all marks
> made on all pages, but their very first example
> of 0 0 612 792 belies this as that's not a reasonable value.  (If the
> pages truly are intended to bleed, this box
> should be larger by at least a couple of points in each dimension; if the
> pages don't bleed, it should be smaller
> by some reasonable margin).
>
> But following this example, way back in the 80's, I made the dvips
> bounding box be a "rounded up" version of
> the paper size.  The paper size itself can be specified in a special, and
> the user can use whatever units and
> rounding in that specification they desire, so a certain amount of slop is
> unavoidable.  This is why dvips allows a
> certain amount of slop when matching media sizes.
>
> Now, the code clearly doesn't do precisely what the comment says it does,
> and this is a problem, and will be fixed,
> 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
> avoid it.  For EPSF file generation it's critical that the bounding box be
> rounded *up* (or a hi res bounding box
> provided, but I'm not sure that ever got fully blessed by Adobe and/or
> what software might support it).  So I'm
> tempted to maintain the rounding up behavior.  And 210mm rounds *up* to
> 596 bp, so that number will stay.
>
> The current code does not always round up, but if it ever rounds down it
> will round down only by less than a
> millionth of an inch, which is unlikely to be discerned by a casual
> viewer.  And the bounding box should *not*
> be used as a clip box except in very specific uses.
>
> If people are using the values in the bounding box and comparing them
> against (say) ISO 216 paper sizes and
> expecting an exact match, they may be disappointed.  But I see no reason
> they should match.  If anyone does,
> and can point me to a specification and use case for a multipage bounding
> box, I may reconsider.
>
> So I think we'll likely improve the rounding in the code to round up using
> exact integer arithmetic (using a simple
> approach for clarity), but there's no rush to make that happen.  The
> chances of that changing the dvips output
> bounding box for practically any real-world document is pretty negligible,
> so we'll do it just to polish the internal
> code a tiny bit.
>
> -tom
>
> On Sun, Mar 10, 2024 at 2:28 PM Al Ma <alma0 at ro.ru <http:///compose>>
> wrote:
>
>> > What is the practical problem …?
>>
>> @Tom Thank you for a reply.
>>
>> 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.
>>
>> A bug report that, although with a subjectively low chance, might be
>> related is http://bugs.debian.org/1036115 .
>>
>> Beyond that, I am driven by curiosity.
>>
>> 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.
>>
>> Finally, David suggested in
>>
>>
>> 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
>>
>> that I submit a bug at tex-live, so I did.
>>
>> @Karl Alright, posting to tex-k instead of tex-live.
>>
>>
>
> --
> -  https://cube20.org/ <http://cube20.org/>  -  https://golly.sf.net/
> <http://golly.sf.net/>  - https://alpha.twizzle.net/
> / -
>
>

-- 
-  https://cube20.org/ <http://cube20.org/>  -  https://golly.sf.net/
<http://golly.sf.net/>  - https://alpha.twizzle.net/
/ -
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://tug.org/pipermail/tex-k/attachments/20240310/561890ed/attachment-0001.htm>