🚀 go-pugleaf

In article <7894@cg-atla.UUCP> bradlee@cg-atla.UUCP (Rob Bradlee) writes:
>In article <7893@cg-atla.UUCP> felleman@cg-atla.UUCP (John Felleman) writes:
>>Actually, I don't think the EPSF document was recommending that you actually
>>measure each document you created for export. Rather, the correct bounding
>>box was defined as what you would get if you did measure it by hand.
>
>I love to disagree with my co-worker and friend John.  As I read the EPSF
>spec it sure sounds to me that Adobe is recommending that you measure by
>hand to determine the bounding box.  If they are saying that you can
>test the correctness of your calculation by measuring by hand, then they 
>should say so in the next revision of the document.  But just to destroy
>a good theoretical net argument, I'll mess it up with some factual details.
>Here's the way the spec reads:
>
>	"Regardless of the coordinate system in which your application
>	operates, here is a fooproof way of determining the correct 
>	bounding box: print the page, get out a point ruler, and measure 
>	first to the lower left corner, then to the upper right corner,
>	using the lower-left corner of the physical paper as your origin.
>	This works because it measures the end result (the marks on the
>	page), and none of the computation matters.
>
>(By the way I really like how they use lower-left unhyphenated and hyphenated
>in the same paragraph.)

Well, I wrote that paragraph, so you can blame me.  Just to add an
extra row of >> to the discussion, I thought I would toss in my two
cents' worth.

Bounding boxes, for some reason, have caused a lot of confusion for
people, both those who need to produce them and those that need to read
them.  In fact, I listened to someone on the phone for literally two
and a half hours (with the emphasis on listened) explaining to me why
you just COULD NOT express the bounding box in default user-space
coordinates, that it would NEVER WORK.  It had to be in the native
coordinate systems of the application.  He was wrong, of course, but
nothing I could say would convince him otherwise (in fact, it caused
him to declare how snobbish Adobe was that they wouldn't listen to
him).  Luckily, I've completely forgotten who the individual was.  In
any case, it helped drive home the point that people argued a lot over
what should be the bounding box for a particular graphic.  A lot of
PostScript printer drivers, for various mysterious reasons, scale and
flip the default user space to something else, which makes it more
difficult for them to compute the bounding box in regular ol' user
space (You've seen them, I'm sure; the middle of the page is at the
coordinate 8000 -11500 or whatever.)

That's why, in the EPSF documentation, I suggested printing it out and
measuring it (John Felleman's interpretation above was exactly what I
had in mind, in fact).  It settled the argument once and for all, at
least to me, since the method is independent of any computer program.
It is difficult to describe a bouding box in terms of the program you
should write to calculate it, so I tried to describe it in terms of
what the final result should be, and to provide a sort of "sanity
check" so you'd know if it was right or not.  Of course, it probably
really is easier than writing a program to determine it, and it is very
reliable, unless part of the image is off the page, which can be the
case.  However, it is not really intended as a production solution for
people who are trying to incorporate 1,000 illustrations into a book on
astrophysics.

Of course, it is *perfectly legal* for a bounding box to be completely
off the page.  In fact, Adobe Illustrator does this by default, to
keep the Y axis growing downward without inverting the coordinate
system.  If you print an Illustrator file directly, without adjusting
for the bounding box, very often it will be off the bottom edge of
the page (which the bounding box reflects by having negative Y
coordinates for both the "lower-left" (or is it "lower left?") corner
and the upper right corner.  But if you parse the bounding box
correctly, you can position the graphic anywhere on the page you
want simply by using "translate".  Just as a reminder, you can ALWAYS
locate an EPSF graphic at the lower-left corner of the physical
page with the following algorithm:

	* parse the bounding box and get the LLx and LLy values
	  (lower-left X coordinate and lower left Y coordinate).

	* precede the EPSF code with the following:

		LLx neg LLy neg translate

Anyway, that's my two cents' worth.  I just couldn't resist.  And as
for the "lower left" and "lower-left" inconsistency, I meant to do
that.  Really.  I'm glad, at least, that people are reading the spec
that carefully :-)

Glenn Reid
Adobe Systems