Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!sun-barr!decwrl!adobe!jeynes
From: jeynes@adobe.COM (Ross A. Jeynes)
Newsgroups: comp.lang.postscript
Subject: Re: BoundingBox from Illustrator
Keywords: BoundingBox
Message-ID: <1518@adobe.UUCP>
Date: 12 Dec 89 00:24:20 GMT
References: <31084@iuvax.cs.indiana.edu>
Reply-To: jeynes@adobe.UUCP (Ross A. Jeynes)
Distribution: na
Organization: Adobe Systems Incorporated, Mountain View
Lines: 91


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