EPS

[Prof Brian D Ripley]

On Fri, 30 Oct 1998 Ted.Harding@nessie.mcc.ac.uk wrote:

> On 29-Oct-98 Paul Gilbert wrote:
> > Perhaps this has been mentioned and I wasn't paying attention. When I
> > try to import a postscript file (which is EPS according to the R help on
> > postscript) my Framemaker filter chokes. If I simply edit the first
> > line of the file to put
> > 
> > %!PS-Adobe-3.0 EPSF-3.0
> > rather than
> > %!PS-Adobe-3.0
> > 
> > it works just fine. It sure would be simpler if the postscipt driver
> > put this in the file.

Given that everyone else has to have filters to correct FrameMaker's PS
exports to be valid EPS, perhaps writing a filter for import to FrameMaker
would be poetic justice.  You make this change by a one-line sed or perl
command. 

> It shouldn't have to. The PostScript Document Structuring Conventions
> allow both forms "%!PS-Adobe-3.0" and "%!PS-Adobe-3.0 EPSF-3.0" with
> the rider "Document composition programs should not use these keywords
> [namely "EPSF-3.0" and others] when producing a document intended for
> printing or display. Instead, they should use only the "%!PS-Adobe-3.0"
> comment. Illustration applications may also use the EPSF-3.0 keyword."
> 
> Note "may also use". Since an EPS file can be recognised anyway by the
> presence of %%BoundingBox somewhere, the EPSF-3.0 is not necessary.

Sorry, but no, they cannot (see later on the same page as the note you
quoted earlier). Any PostScript file may have %%BoundingBox comment in it,
and many non-EPSF files do (notably those produced by S-PLUS for Windows). 
(Note: I am distinguishing the EPSF file format from EPS files; there are
additional requirements).

> Forcing R to produce "!PS-Adobe-3.0 EPSF-3.0" could break
> printing/display software which conforms to the DSC according to the
> above quote. The limitations of one program (Framemaker) should not
> be used as a reason for producing output which could defeat compliant
> software.

It will not defeat properly written DSC-compliant software if it is really
an EPSF file: but see below. Some print spoolers (notably some of HP's) 
fail the caveat in my experience -- even at HP's own labs.

> However, I wouldn't be against having "EPSF-3.0" as a user-selectable
> option.

Paul did not tell us which version of R he is using, and the postscript()
driver has been changed in 0.63. However, I believe that if it does produce
a valid EPSF file it should have EPSF-3.0 in the header, and if it does not
it should definitely not.

My belief is that R's postscript() does meet the requirements for EPS, but
the files will be EPSF only if they contain a single plot.  It is not for
nothing that Allan Wilks' S postscript driver has arguments onefile=F,
print.it=F for EPSF files (this means the plots are put in separate files).

BTW, that help page says

     The postscript produced by R is EPS (Encapsulated
     PostScript) compatible, and can be included into other
     documents, e.g. into LaTeX, using
     `\psfig{file=<filename>}'.

and psfig has never been part of LaTeX and has been deprecated by the LaTeX
team since the former LaTeX2e became LaTeX in 1994. The preferred way is
the graphics/graphicx packages; these make the interim epsfig package
defunct.

Brian

-- 
Brian D. Ripley,                  ripley@stats.ox.ac.uk
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford,             Tel:  +44 1865 272861 (self)
1 South Parks Road,                     +44 1865 272860 (secr)
Oxford OX1 3TG, UK                Fax:  +44 1865 272595

-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-devel-request@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._