[Date Prev][Date Next][Thread Prev][Thread Next][Date index][Thread index]

From |
Lee Sieswerda <Lee.Sieswerda@tbdhu.com> |

To |
"'statalist@hsphsun2.harvard.edu'" <statalist@hsphsun2.harvard.edu> |

Subject |
RE: st: Graphics translation: eps bounding box question |

Date |
Thu, 8 Aug 2002 11:06:51 -0400 |

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: Eva.Poen@student.unisg.ch [SMTP:Eva.Poen@student.unisg.ch] > Sent: Wednesday, August 07, 2002 4:53 PM > To: statalist@hsphsun2.harvard.edu > 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/

- Prev by Date:
**Re: st: outreg => table output** - Next by Date:
**RE: st: Graphics translation: eps bounding box question** - Previous by thread:
**Re: st: Graphics translation: eps bounding box question** - Next by thread:
**RE: st: Graphics translation: eps bounding box question** - Index(es):

© Copyright 1996–2017 StataCorp LLC | Terms of use | Privacy | Contact us | What's new | Site index |