[tex-k] dvips bounding box

Mon Mar 11 10:24:22 CET 2024

Hi,

there are several different things:

1. Office printers with several trails ezch with a different page
size. The printer then can choose the best input trail.

2. Prepress, this needs MediaBox, TrimBox, BleedBox as specified in
PDF/X but these boxes can also be specified in PS code (but not in the
coments)

3. Graphics inclusion, in PDF ArtBox is the right solution but
pdftex/xetex can use any of them. It can be set in PS code but tex
probably cannot read it from PS.

If I remember the specification well, in case of a multipage document
each page must fit inside %%BoundingBox. The specification doe not say
whether the box must be tight, thus a white space around is allowed.

Zdeněk Wagner
https://www.zdenek-wagner.eu/

po 11. 3. 2024 v 5:35 odesílatel Tomas Rokicki <rokicki at gmail.com> napsal:
>
> 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> 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/  -  https://golly.sf.net/  - https://alpha.twizzle.net/
>> / -
>>
>
>
> --
> -  https://cube20.org/  -  https://golly.sf.net/  - https://alpha.twizzle.net/
> / -