Path: utzoo!attcan!utgpu!trigraph!john From: john@trigraph.uucp (John Chew) Newsgroups: comp.lang.postscript Subject: Re: BoundingBox from Illustrator Message-ID: <1989Dec11.192516.546@trigraph.uucp> Date: 11 Dec 89 19:25:16 GMT References: <31084@iuvax.cs.indiana.edu> Sender: "John J. Chew" Reply-To: "John J. Chew" Organization: Trigraph Inc., Toronto, Canada Lines: 41 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)? As has been pointed out before, Adobe Illustrator does not always produce Adobe DSC-conforming files. In particular, under some circumstances it will produce fractional values for the co-ordinates in a %%BoundingBox: comment. However, the two points that you raised are inaccurate. According to section 4.1 (Parsing Rules) of version 2.1 of the Document Structuring Conventions Specification (January 16, 1989): "Comments with arguments (like %%Page) should have a space separating the colon from the first argument. Unfortunately, due to existing software, this space must be considered optional." 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. Another problem that we have encountered with %%BoundingBox: is that its bounds are often quite conservative. They can include several points of white space around an illustration, which can be extremely annoying when you are trying to automatically place a few thousand illustrations. My suspicion is that this is caused by fitting the bounding box around all spline control points instead of actual ink marks, which might have sounded like a reasonable optimization to the developers of Adobe Illustrator. John -- john j. chew, iii phone: +1 416 425 3818 AppleLink: CDA0329 trigraph, inc., toronto, canada {uunet!utai!utcsri,utgpu,utzoo}!trigraph!john dept. of math., u. of toronto poslfit@{utorgpu.bitnet,gpu.utcs.utoronto.ca}