🚀 go-pugleaf

lee@sq.sq.com (Liam R. E. Quin) writes:
 
> I don't think you can [determine what the width of the page and
> the height of the page is] portably in an EPS file, though.
 
Why would anyone want to know what the page size is in an *EPS*
file!? The whole point of EPS is that it doesn't make
assumptions about the importing environment.  The importing
application might want to map the EPS picture onto an arbitrary
surface, perhaps not even resembling a page outline.
 
I have written an ECAD application that generates an EPS file
which assumes a default coordinate system of 0.001".  The
bounding box comment is also given in the same coordinate
system.  A typical image just fits the page at 1-to-1 scaling. 
If you just send one of these files to the  printer, the image
will be way to big to fit on the paper (about 1000/72 too big).
 I run the resulting file through a post-processor to scale the
EPS by 72/1000 and center the resulting image on the page.
 
Why would I do such a thing?  Well, the EPS spec requires that
the bounding box be given in integral points.  By retaining the
original coordinate system of the application, I get greater
precision in the bounding box.  Of course, any importing
application must be able to handle an image considerably larger
than a normal sheet of paper.
 
One thing to look out for in importing applications is whether
they provide enough bits for their scaling operations when
importing an EPS file.  Borland Sprint fails here, as it does
all calculations in 16 bits, and its coordinate system is 1800
units/inch.  I had to fudge Borland's EPS scaling macro to
synthesize some extra precision so that images wouldn't run off
into surrounding text (this involved implementing a
multiple-precision multiply in Sprint's macro language).  Try,
for example, to import the AutoCAD Space Shuttle drawing: the
tail fin pokes up into the text above the drawing because
roundoff causes Sprint to assume the picture is smaller than
it is.
 
Ken (shiva@well.sf.ca.us)