[tex-k] dvips bounding box

[Tomas Rokicki]

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/ <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/ef83bde3/attachment.htm>