🚀 go-pugleaf

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.