felleman@cg-atla.UUCP (John Felleman) (11/09/89)
In article <5553@ubc-cs.UUCP> halliday@cc.ubc.ca (Laura Halliday) writes: >In article <3094@husc6.harvard.edu> nowlin@gramian.UUCP (Bill Nowlin) writes: >>A simple question that I expect has a simple answer: > >There is an extremely effective, absolutely foolproof way of doing this. > >Print the page and measure it. If you don't have a ruler calibrated in >points, get one. Even Adobe recommend this - see the EPSF document for >details. > 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. Unfortunately, figuring out the extent of all the objects on a page requires interpreting the PostScript. I think that is why EPSF asks that the creator supply the info in the BoundingBox comment. You are stuck with a program that obeys the letter but not the spirit of the law. -- John Felleman (508)-658-5600 X7034 AGFA Compugraphic ...!{ima,ulowell,ism780c}!cg-atla!felleman 200 Ballardvale St. Wilmington, Mass. 01887 [This space available for rent]
bradlee@cg-atla.UUCP (Rob Bradlee) (11/09/89)
In article <7893@cg-atla.UUCP> felleman@cg-atla.UUCP (John Felleman) writes: >In article <5553@ubc-cs.UUCP> halliday@cc.ubc.ca (Laura Halliday) 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. >-- >John Felleman (508)-658-5600 X7034 >AGFA Compugraphic ...!{ima,ulowell,ism780c}!cg-atla!felleman >200 Ballardvale St. >Wilmington, Mass. 01887 [This space available for rent] 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.) -- Rob Bradlee w:(508)-658-5600 X5153 h:(617)-944-5595 AGFA Compugraphic Division. ...!{decvax,samsung}!cg-atla!bradlee 200 Ballardvale St. Wilmington, Mass. 01887 The Nordic Way: Ski till it hurts!
decouty@irisa.fr (Bertrand Decouty) (11/09/89)
In article <7893@cg-atla.UUCP> felleman@cg-atla.UUCP (John Felleman) writes: | In article <5553@ubc-cs.UUCP> halliday@cc.ubc.ca (Laura Halliday) writes: | >In article <3094@husc6.harvard.edu> nowlin@gramian.UUCP (Bill Nowlin) writes: | >>A simple question that I expect has a simple answer: | | > | >There is an extremely effective, absolutely foolproof way of doing this. | > | >Print the page and measure it. If you don't have a ruler calibrated in | >points, get one. Even Adobe recommend this - see the EPSF document for | >details. | > | You can also try 'bbfig' from Ned Batchelder, which is a PostScript prologue downloaded before your PS file. Warning: it does not ALWAYS work. | Bertrand DECOUTY | EMAIL : decouty@irisa.fr, decouty@irisa.uucp | | IRISA - INRIA | {uunet,mcvax,inria}!irisa!decouty | | Campus de Beaulieu | PHONE : +33 99 36 20 00 | | F-35042 Rennes Cedex - FRANCE| FAX : +33 99 38 38 32 | TELEX: 950473 UNIRISA|
greid@adobe.com (Glenn Reid) (11/10/89)
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
des@elberton.inmos.co.uk (David Shepherd) (11/11/89)
In article <5553@ubc-cs.UUCP> halliday@cc.ubc.ca (Laura Halliday) writes: >In article <3094@husc6.harvard.edu> nowlin@gramian.UUCP (Bill Nowlin) writes: >>Is there a readily available program (PostScript, or even C) that figures >>the smallest bounding box based on the graphics found in a file? > >There is an extremely effective, absolutely foolproof way of doing this. > >Print the page and measure it. If you don't have a ruler calibrated in >points, get one. Even Adobe recommend this - see the EPSF document for >details. better still, prepend a bit of PostScript onto the front of the file to draw a grid on the page so that you can work out directly the bounding box relative to the co-ordianet system in action at the start of the file. A simple shell script in Unix will do all this mechanically for you. david shepherd INMOS ltd
ken@cs.rochester.edu (Ken Yap) (11/11/89)
Ok, next question, well actually three. Why is the BoundingBox specified in integer units? What about applications that need to position inserts more accurately? And what do we do with programs that violate the standard by generating floating point values for BBs, like Arbortext's pubdraw/vecps.
woody@rpp386.cactus.org (Woodrow Baker) (11/13/89)
There is a related topic to bounding boxes. I have tried without success to get the bounding box for a font. I must be doing something wrong, because the documentation in the red-book just doesnot seem to work for me. The problem is converting a proportional spaced font (like Times-Roman) to a monospaced font. Yeah, I know, why on earth would I want to do this? Well, A client is paying me good money to solve a problem for him. His requirement is that he be able to print any font in mono-mode so that the old software that he has will work correctly. I have written a COMPLETE Diablo emulator for him, and sofar have done the mono-stuff the hard way. It is realy to slow to compute each character width, and then subtract it from the cell width, divide diff by 2 and move that amount before printing the character, but that is the way I had to do it. The books imply that you can change the character widths of a font, and so you can. Unfortunaly Adobe does not center proportional characters within the font bounding box, so one has to alter the sidebearing info. I can only find a fleeting mention that the metrics entry can be a matrix either 1 or 2 elements wide. There is also a passing hint that given the font bounding box, and the char bounding box one can somehow compute a sidebearing. I have had no luck doing either. Can anyone shed some light on this, and possibly post a fragment of code (Hello Adobe....) I'd surely appreciate this. Cheers, Woody