From ripley at stats.ox.ac.uk  Wed Oct  8 14:19:17 2003
From: ripley at stats.ox.ac.uk (Prof Brian Ripley)
Date: Wed Oct  8 14:19:01 2003
Subject: [Rd] Unpredictable EPS->PDF rotation (PR#4460)
In-Reply-To: <XFMail.031008120346.Ted.Harding@nessie.mcc.ac.uk>
Message-ID: <Pine.LNX.4.44.0310081309120.1883-100000@gannet.stats>

For the record, gs 6.20 introduced

<p>
This fileset includes the first steps towards bringing the pdfwrite driver
closer to matching Acrobat Distiller 4.  Highlights:

<ul>

<li> Reimplementation of CIDFontType 0 support in C rather than 
PostScript;

<li> Parsing (but not functional implementation) of nearly all the Acrobat
Distiller 4 parameters;

<li> Implementation of AutoRotatePages and DCTEncode filtering in the PDF
writer;

<li> A PDF linearizer ("optimizer").

</ul>

and so all recent versions of gs work like Distiller, with the default for
the parameter AutoRotatePages=/PageByPage.

R's EPS used to specify portrait orientation, but at about the same time 
gs changed the interpretation of that from `don't rotate' to `width < 
height' and so would have rotated both examples, and we removed the DSC 
orientation line.

The reason the first is not rotated and the second is is that the x-axis
strings are longer in the first, and so the majority of the text on the
page is horizontal in the first but not the second (and the main
determinant for autorotation is the orientation of the text).


So, no mystery, just ghostscript working as documented.  And no R bug!


On Wed, 8 Oct 2003 Ted.Harding@nessie.mcc.ac.uk wrote:

> On 08-Oct-03 arnima@u.washington.edu wrote:
> > When I create EPS files, they sometimes appear rotated in my LaTeX PDF
> > document and sometimes they don't. Two examples:
> > 
> >## x1.eps is not rotated in LaTeX
> > x <- seq(-1, 1, length=100)
> > postscript("c:/x1.eps", height=3, width=4,
> >            horizontal=FALSE, onefile=FALSE, paper="special")
> > plot(x, dnorm(x), type="l")
> > dev.off()
> > 
> >## x2.eps is not rotated in LaTeX
> > x <- seq(-2, 2, length=100)
> > postscript("c:/x2.eps", height=3, width=4,
> >            horizontal=FALSE, onefile=FALSE, paper="special")
> > plot(x, dnorm(x), type="l")
> > dev.off()
> > 
> > By LaTeX PDF, I am referring to the dvips->ghostscript pathway, but
> > x2.eps
> > also rotates when distilled into PDF outside LaTeX. I have tried
> > ghostscript and acrobat, placed on a page or cropped, so the problem
> > does not seem to be confounded with particular PDF distillation
> > software.
> 
> I've done an experiment or two (and I've read Peter Dalgaard's reply).
> 
> Using Red Hat 9, I imported the two files x1.eps and x2.eps as output
> by R-1.7.1 into a groff document, both on one page and one above the
> other, outputting the result as a PS file, temp.ps.
> 
> Using ghostview, the result displayed fine: right way up.
> 
> Then distilled this to PDF, using (a) ps2pdf from ghostscript 7.05,
> then (b) epstopdf from TeX (though this too calls ghostscript).
> In both cases, the entire page displayed in Acrobat Reader rotated
> right through 90 degrees, i.e. the wrong way round.
> 
> Then I transferred the temp.ps file to two other machines.
> 
> [A] On one, SuSE Linux 5.2, I have an elderly copy of PStill (See Frank
> Siegert's site http://www.pstill.com ) which actually is a better
> distiller than ghostscript provides. The resulting PDF displayed right
> way up using acroread 3.0. I then converted to PDF using ps2pdf
> (ghostscript 5.10) and again it was the right way up.
> 
> [B] On the other, SuSE Linux 7.2, I converted using ps2pdf (ghostscript
> 5.50) and again it was the right way up when viewed with acroread 4.0.
> 
> Then I transferred both PDF files, from [A] and from [B], back to the
> original Red Hat 9 machine and viewed each using aroread 5.0, and they
> were still the right way up.
> 
> It would seem from this that the problem arises with the distillation
> using ghostscript 7.05 (I don't have access to Acrobat Distiller).
> 
> BY THE WAY: I had a look at the PostScript code in the EPS files from R,
> and noticed that the begin-page and end-page definitions use double
> invocations of gsave and grestore:
> 
>   /bp  { gs gs } def
>   % begin .ps.prolog
>   /gs  { gsave } def
>   /gr  { grestore } def
>   /ep  { showpage gr gr } def
> 
> This doesn't strike me as necessary, so (in case it might have something
> to do with it) I removed one of them in each case:
> 
>   /bp  { gs } def
>   % begin .ps.prolog
>   /gs  { gsave } def
>   /gr  { grestore } def
>   /ep  { showpage gr } def
> 
> to see if it made any difference (it didn't).
> 
> I hope this helps to advance the investigation!
> 
> Best wishes,
> Ted.
> 
> ______________________________________________
> R-devel@stat.math.ethz.ch mailing list
> https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
> 
> 

-- 
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 272866 (PA)
Oxford OX1 3TG, UK                Fax:  +44 1865 272595


[Rd] Unpredictable EPS->PDF rotation (PR#4460)
Prof Brian Ripley