hess@iuvax.cs.indiana.edu (Caleb Hess) (12/08/89)
produced by Adobe Illustrator 1.1: %%BoundingBox:159 -200 416 -10. Our system (psfig/tex, Rokicki's dvips) has two problems with this. First, psfig doesn't parse it, because it expects a space after the :. Second, dvips interprets the negative y values as placing the figure below the origin, and moves it up accordingly, so that the figure is placed far above the 11" page. Why does Adobe Illustrator produce code which doesn't conform to Adobe's EPSF Spec. (I have version 2.0, 11/1/88)? Using the method described on p.5 under %%BoundingBox: (print the figure and measure), how is it possible to come up with negative values? Has version 1.1 of Illustrator been superceded by something that does produce reasonable EPSF code? Or am I missing something?
john@trigraph.uucp (John Chew) (12/12/89)
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}
jeynes@adobe.COM (Ross A. Jeynes) (12/12/89)
In article <31084@iuvax.cs.indiana.edu> hess@iuvax.cs.indiana.edu (Caleb Hess) writes: >produced by Adobe Illustrator 1.1: %%BoundingBox:159 -200 416 -10. >Our system (psfig/tex, Rokicki's dvips) has two problems with this. >First, psfig doesn't parse it, because it expects a space after the :. This is a known bug in Illustrator 1.1, but quoting from the Document Structuring Conventions 2.1: "Comments with arguments should have a space separating the colon from the first argument. Unfortunately, due to existing software, this space must be considered optional." In the past (and even at the present), the Structuring Conventions have been rather loosely implemented. Part of this is due to the lack of a validation suite; witness the recent flames in this newsgroup. Generally, though, the more exceptions your software can handle, the more EPS files your software will read. There are some common mistakes that people make when implementing their drivers that will cause parsers to break. Some are easy to check for, like spaces between the ":" and parameters following a comment, or missing parameters (i.e. %%DocumentFonts: ). Of course, this additional code adds development time and bytes to the final product. The point is, it's all a tradeoff. The Document Structuring Conventions are known to be loosley implemented. When reading documents that claim to be conforming, significant error checking still needs to be done. The more error checking your code does, the longer it takes to develop, and the bigger it is, but the happier your users will be. This error checking will continue to be needed until 1) The Document Structuring Conventions document itself is revised and clarified, and 2) Programs properly support output of the Document Structuring Conventions. (Actually, it will probably continue to be needed long after that, since there are so many pseudo-conforming documents out there now.) I am going to begin a revision of the Document Structuring Conventions in the near future, and would like to hear from anyone who has suggestions. (Don't hold your breath for a reply, though, as I'm sure this is going to generate a lot of mail. :-) And, Yes, a validation suite is on the List Of Important Things To Do for developer support. There are some quick ways to check if you've implemented the comments correctly, however, barring the existence of such a test program. - Downloading the prolog outside the server loop, then sending down just the script from a document. - Reversing pages (if you support %%Page:) by hand with a text editor. - Including the document in some applications that support including EPS files, like Illustrator, PageMaker, WordPerfect, etc. I understand that the NeXT previewer does a good job of reading comments. - Take out ProcSets which aren't necessary, reverse the ProcSets, etc. >Why does Adobe Illustrator produce code which doesn't conform to Adobe's >EPSF Spec. (I have version 2.0, 11/1/88)? Using the method described on >p.5 under %%BoundingBox: (print the figure and measure), how is it possible >to come up with negative values? Has version 1.1 of Illustrator been >superceded by something that does produce reasonable EPSF code? Or am I >missing something? Yes, there is a newer version of Illustrator (Illustrator '88) that corrects this problem, and adds a lot of other functionality. (Unfortunately, not all of the other Structuring Conventions comments are implemented properly in Illustrator '88.) It is legal to have negative values for the bounding box; this just means that the document would image off (below) the page, if sent directly to the printer. To print the file properly, take the llx and lly from the %%BoundingBox and do a llx neg lly neg translate then include the rest of the file. This moves the document up to the lower- lefthand corner of the page. Perhaps psfig is assuming that the document's bounding box begins at (0, 0), or perhaps it isn't taking into account a scale factor, so it ends up translating the document further than it needs to. (This is an important, but subtle point that often confuses people: the BoundingBox coordinates must be specified in the default coordinate system. When including a file, be sure to account for any scale factor in effect at the time of the translation done to position the document.) Net answer: (no pun intended) it is legal to have bounding boxes which do not image on the page. The including software should parse for %%BoundingBox, and translate accordingly. I hope all this rambling has helped. Ross Jeynes Developer Support jeynes@adobe.com Adobe Systems Incorporated {sun|decwrl}!adobe!jeynes
hess@iuvax.cs.indiana.edu (Caleb Hess) (12/12/89)
In article <1989Dec11.192516.546@trigraph.uucp> "John J. Chew" <poslfit@gpu.UTCS.UToronto.CA> 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.