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/
