Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!aplcen!samsung!zaphod.mps.ohio-state.edu!tut.cis.ohio-state.edu!cica!iuvax!hess From: hess@iuvax.cs.indiana.edu (Caleb Hess) Newsgroups: comp.lang.postscript Subject: Re: BoundingBox from Illustrator Summary: dvips handles BoundingBox OK Message-ID: <31394@iuvax.cs.indiana.edu> Date: 12 Dec 89 14:53:11 GMT References: <31084@iuvax.cs.indiana.edu> <1989Dec11.192516.546@trigraph.uucp> Reply-To: hess@iuvax.cs.indiana.edu (Caleb Hess) Distribution: na Organization: Indiana University, Bloomington Lines: 32 In article <1989Dec11.192516.546@trigraph.uucp> "John J. Chew" writes: >In <31084@iuvax.cs.indiana.edu> hess@iuvax.cs.indiana.edu (Caleb Hess) writes: >>produced by Adobe Illustrator 1.1: %%BoundingBox:159 -200 416 -10. >... >>Why does Adobe Illustrator produce code which doesn't conform to Adobe's >>EPSF Spec. (I have version 2.0, 11/1/88)? > >Then in the description of the %%BoundingBox: header comment in section >5.1 (Header Comments) in the same document, the four arguments are declared >to be integers. There is no restriction that they must be non-negative >integers, and if a particular application's representation of an >illustration finds it convenient to build an illustration partly off >the normal page area, there is no reason why it should not do so. It >seems that your parsing software is being unnecessarily restrictive. > I should have described the problem more thoroughly. When printed by itself, the figure in question prints near the top of the page, hence the question about negative BoundingBox values. On further examination, I discovered that the figure contained the comment "%%PS-Adobe-2.0 EPSF-1.2", indicating pre-2.0 EPSF comments. It appears that the origin was taken to be at the upper left, inside a top and side margin. Lest anyone should take the previous discussion as a negative reflection on Rokicki's dvips program, let me add that dvips handled the negative values correctly, had they correctly described the placement of the figure relative to the PostScript page origin. That is, the area below the origin was placed at the correct location in the document. Unfortunately, this put the actual figure above the imageable area of the page, causing great consternation among the writers of the document (Hey, how come the figure didn't print?). I discovered this by using the obvious test: capture the final PostScript before it goes to the printer, and add "306 396 translate .25 .25 scale" at the top.