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
with "di".
Lee Sieswerda
> -----Original Message-----
> From: Lee Sieswerda [SMTP:[email protected]]
> Sent: Thursday, August 08, 2002 11:07 AM
> To: '[email protected]'
> 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
> you
> 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
> (integer-ized)
> %%BoundingBox comment. I'm not sure how useful this ado will be in the
> long
> 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.
>
> Regards,
>
> 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
> *********end epsbb2int.ado************
>
>
> > -----Original Message-----
> > From: [email protected] [SMTP:[email protected]]
> > Sent: Wednesday, August 07, 2002 4:53 PM
> > To: [email protected]
> > Subject: Re: st: Graphics translation: eps bounding box question
> >
> >
> > [...]
> >
> > > >
> > > >1) The bounding box is not given in integers, but as i.e. "0.000
> 0.000
> > > >432.000 288.000". This causes ghostview/-script to complain. It
> should
> > be
> > > >"0 0 432 288".
> >
> > Roger writes:
> >
> > > What version of GhostView/Script are you using? I use GSView Version
> 4.2
> > > (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
> you
> > > launch it about becoming a registered user.
> >
> > Roger,
> > I use latest gsview and ghostscript. Gsview does exactly what you say,
> but
> > 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
> below
> > 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)
> the
> > > bounding box fits nicely round the graph, in my experience, except
> when
> > 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
> the
> > > 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
> -c
> > -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:
* http://www.stata.com/support/faqs/res/findit.html
* http://www.stata.com/support/statalist/faq
* http://www.ats.ucla.edu/stat/stata/
