Oops, I forgot to delete the -display- lines from the ado I sent (below).
They were just in there for troubleshooting and don't effect the program per
se. They just create some useless output. You can delete any line beginning
> -----Original Message-----
> From: Lee Sieswerda [SMTP:Lee.Sieswerda@tbdhu.com]
> Sent: Thursday, August 08, 2002 11:07 AM
> To: 'email@example.com'
> Subject: RE: st: Graphics translation: eps bounding box question
> According to Adobe:
> "Because %%HiResBoundingBox: is a new comment that is not in the current
> DSC 3.0 specification, DSC producers that use it should also continue to
> include the %%BoundingBox: comment for use by the applications that
> rely on it. Note that %%BoundingBox: is required in EPS files even if
> %%HiResBoundingBox: is present."
> I wrote a little ado (below) which makes Stata-generated EPS files conform
> to this standard. To use the command, first, you translate to eps, then
> run this little ado to modify the EPS. For example:
> translate @Graph test.eps, replace
> epsbb2int using c:\stata\test.eps
> The new EPS will have the %%HiResBoundingBox comment and the
> %%BoundingBox comment. I'm not sure how useful this ado will be in the
> term. When StataCorp incorporates the new graphics capabilities, the
> translate commands will presumably be revised. But, for now, it seems to
> work well. BTW, it only works on Stata-generated EPS files because it uses
> -file seek- to get to a specific byte location.
> Lee Sieswerda
> *****begin epsbb2int.ado*********
> *! version 1.0 Lee Sieswerda 7 July 2002
> prog define epsbb2int
> version 7.0
> syntax using
> * This program converts the bounding box coordinates of a
> * specified EPS file into integers. It also turfs the second
> * line comment and replaces it with a HiResBoundingBox
> * comment. This command ONLY works on
> * Stata-generated EPS files owing to the -file seek-
> * command having to go to a specific byte position.
> * For syntax, simply type:
> * epsbb2int using <filename>
> tempname myfile
> file open myfile `using', read write text
> file seek myfile 25
> file read myfile del_line
> local del_line_length: length local del_line
> di "`del_line_length'"
> file seek myfile 71
> file read myfile line
> local len_orig: length local line
> di "`len_orig'"
> tokenize `line'
> local hires_line = "%%HiResBoundingBox `2' `3' `4' `5'"
> local hires_line_length: length local hires_line
> di "`hires_line_length'"
> local hires_len_diff = `del_line_length' - `hires_line_length'
> di "`hires_len_diff'"
> file seek myfile 25
> file write myfile "`hires_line'" _n
> local 2 = int(`2')
> local 3 = int(`3')
> local 4 = int(`4')
> local 5 = int(`5')
> local newline = "`1' `2' `3' `4' `5'"
> local len_new: length local newline
> local len_diff = `len_orig' - `len_new' + `hires_len_diff'
> file write myfile "`1' `2' `3' `4' `5'" _skip(`len_diff') _n
> file close myfile
> *********end epsbb2int.ado************
> > -----Original Message-----
> > From: Eva.Poen@student.unisg.ch [SMTP:Eva.Poen@student.unisg.ch]
> > Sent: Wednesday, August 07, 2002 4:53 PM
> > To: firstname.lastname@example.org
> > Subject: Re: st: Graphics translation: eps bounding box question
> > [...]
> > > >
> > > >1) The bounding box is not given in integers, but as i.e. "0.000
> > > >432.000 288.000". This causes ghostview/-script to complain. It
> > be
> > > >"0 0 432 288".
> > Roger writes:
> > > What version of GhostView/Script are you using? I use GSView Version
> > > (dated 7 Feb 2002), and it can handle non-integer bounding boxes by
> > > converting them to integers for display purposes, although it queries
> > the
> > > user before doing so. You can download the latest version from
> > > http://www.cs.wisc.edu/~ghost/, although it will nag you every time
> > > launch it about becoming a registered user.
> > Roger,
> > I use latest gsview and ghostscript. Gsview does exactly what you say,
> > epstool refuses to work properly with noninteger bounding boxes.
> > Just to inform everyone about how problem #1 has been solved: Antoine
> > Terracol sent me an ado-file which returns integer bounding boxes. It
> > works
> > wonderful, so if someone else has the same problem, just tell.
> > > >2) The bounding box is calculated too large, leaving white space
> > the
> > > >graph. In my case this is about 1/3 of the whole picture.
> > >
> > > You don't say what version of Stata you are using. Stata .EPS graphs
> > used
> > > to be like that in the days of Stata 6. However, today (in Stata 7)
> > > bounding box fits nicely round the graph, in my experience, except
> > you
> > >
> > > use the -by- option of -graph-, in which case Stata arranges the
> > by-groups
> > > in a square array (so vertical and horizontal scaling are done by the
> > same
> > > factor). In this case, if the number of by-groups is not a perfect
> > square
> > > (eg 1, 4, 9, 16, 25 or 49), Stata wastes the excess space, and puts
> > > bounding box round the full set of graphs that would be present if the
> > > number of by-groups was equal to the next perfect square upwards.
> > This seems to be what is happening. I combine 5 graphs and have some
> > white space below my picture. But now, since my bounding boxes are
> > integer,
> > it is one line at the DOS promt to correct the bounding box: epstool -b
> > -onewpic.eps oldpic.eps
> > Thanks a lot for all replies,
> > best regards,
> > Eva Poen
> > *
> > * For searches and help try:
> > * http://www.stata.com/support/faqs/res/findit.html
> > * http://www.stata.com/support/statalist/faq
> > * http://www.ats.ucla.edu/stat/stata/
> * For searches and help try:
> * http://www.stata.com/support/faqs/res/findit.html
> * http://www.stata.com/support/statalist/faq
> * http://www.ats.ucla.edu/stat/stata/
* For searches and help try: