Unpredictable EPS->PDF rotation (PR#4460)

"PD" == Peter Dalgaard BSA <p.dalgaard@biostat.ku.dk>
    on 08 Oct 2003 11:36:52 +0200 writes:

    PD> arnima@u.washington.edu writes:

    >> Dear r-bugs,
    >>
    >> 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'm aware of the pdf() device in R, but EPS files are a widely used format
    >> to share scientific graphics, often winding up embedded in a PDF document
    >> at a later point in the hands of an editor.
    >>
    >> If at all possible, a more predictable postscript generator would be
    >> appreciated, where EPS figures would not rotate when embedded in PDF
    >> documents.

    PD> I can reproduce the effect on RedHat 8, but I'm at a loss as to
    PD> explain it. The headers and bounding boxes of the two .eps files are
    PD> identical and to the best of my eyesight they are also using the same
    PD> coordinate system.

It's definitely unrelated to R.

The "bug" is in newer versions of gs (ghostscript) which does
rotate plots under some circumstances by default.

Of course, the authors of gs consider this a feature (called
"AutoRotatePages"), but IMO it's been a very bad design-decision.

Here, we have implemented a workaround by patching the
"epstopdf" (shell script) (we use the version from teTeX), by
the following:

--- epstopdf.~1~	2002-04-20 00:00:00.000000000 +0200
+++ epstopdf	2003-03-13 16:43:53.000000000 +0100
@@ -182,6 +182,8 @@
 ### open output file
 if ($::opt_gs) {
   my $pipe = "$GS -q -sDEVICE=pdfwrite $GSOPTS " .
+          "-dAutoRotatePages=/None " . ## MMä: <<<< This is the fix I found via google
+## http://lists.debian.org/debian-tetex-maint/2002/debian-tetex-maint-200202/msg00013.html
           "-sOutputFile=$OutputFilename - -c quit";
   debug "Ghostscript pipe:", $pipe;
   open(OUT,"|$pipe") or error "Cannot open Ghostscript for piped input";

-------------------

I'm interested to hear about more current workarounds /
"official" ways to deal with this ``cool gs feature'' ..