The same problem I am having has been reported here http://tolstoy.newcastle.edu.au/R/devel/04a/0344.html Namely that using par(mfg=...) with a postscript (eps) for inclusion with latex makes the figure appear upside down and back to front (flipped)! Converting the dvi to ps makes matters worse (the eps seems to be broken), however, it appears fine with gv. Here is (basically) the code I am using...>dat <- read.table("x.dmp", header=1) >t(dat)t(dat) 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 CHAINS 1 2 3 4 5 6 7 8 9 10 11 12 13 14 16 20 23 24 26 28 FREQUENCY 886 792 136 201 16 58 6 21 3 9 3 9 1 4 3 1 1 1 1 1> >postscript(+ "x.eps", + width = 6.0, + height = 6.0, + horizontal = FALSE, + onefile = FALSE, + paper = "special", + )> >par(mfg=c(1,1)) >par(mar=c(3,4,1,2)) >plot(dat,type='b') > >par(mfg=c(2,1)) >par(mar=c(4,4,0,2)) >plot(dat,type='b', log='y') > >dev.off()Including the resulting file in a latex document like this... begin{figure} \centering \includegraphics[width=\textwidth]{x.eps} \caption[X] { Hello! } \label{xFig} \end{figure} The result is an upside down (flipped) version of my plot. I tried rotating 180 degrees (based on similar problems people were having on the list), but then it just gets worse (most of the plot is off the page). If I convert the dvi to ps (dvips -Ppdf my.tex.dvi -o my.tex.ps) it gets worse (a tiny speck where the image should be). After removing the two mfg commands (which I use to add grid lines (not shown for clarity)) everything is fine! Some how mfg is snarling things up. OK, I just had a brain wave (dont laugh). Here is a diff of the working eps vs the broken eps... diff broken working 78a79,80> %%Page: 1 1 > bp229c231 < 57.60 43.20 403.20 201.60 cl ---> 57.60 57.60 403.20 216.00 cl417c419 < %%Pages: 0 ---> %%Pages: 1Does that help anyone debug my problem? Like I said, both look identical via gv, and are 'conceptually' identical in R. Here are my vitals Linux 2.4.20-31.9 i686 athlon i386 GNU/Linux R 2.0.0 (2004-10-04). GNU Ghostscript 7.05 (2002-04-22) Anything else you need? Please help!
Should I post this to 'bugs'? On Tue, 26 Apr 2005, Dan Bolser wrote:> >The same problem I am having has been reported here > >http://tolstoy.newcastle.edu.au/R/devel/04a/0344.html > > >Namely that using par(mfg=...) with a postscript (eps) for inclusion with >latex makes the figure appear upside down and back to front (flipped)! > >Converting the dvi to ps makes matters worse (the eps seems to be broken), >however, it appears fine with gv. > >Here is (basically) the code I am using... > >>dat <- read.table("x.dmp", header=1) >>t(dat) >t(dat) > 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 >CHAINS 1 2 3 4 5 6 7 8 9 10 11 12 13 14 16 20 23 24 26 28 >FREQUENCY 886 792 136 201 16 58 6 21 3 9 3 9 1 4 3 1 1 1 1 1 >> >>postscript( >+ "x.eps", >+ width = 6.0, >+ height = 6.0, >+ horizontal = FALSE, >+ onefile = FALSE, >+ paper = "special", >+ ) >> >>par(mfg=c(1,1)) >>par(mar=c(3,4,1,2)) >>plot(dat,type='b') >> >>par(mfg=c(2,1)) >>par(mar=c(4,4,0,2)) >>plot(dat,type='b', log='y') >> >>dev.off() > > >Including the resulting file in a latex document like this... > >begin{figure} >\centering >\includegraphics[width=\textwidth]{x.eps} >\caption[X] >{ >Hello! >} >\label{xFig} >\end{figure} > >The result is an upside down (flipped) version of my plot. I tried >rotating 180 degrees (based on similar problems people were having on the >list), but then it just gets worse (most of the plot is off the page). If >I convert the dvi to ps (dvips -Ppdf my.tex.dvi -o my.tex.ps) it gets >worse (a tiny speck where the image should be). > >After removing the two mfg commands (which I use to add grid lines (not >shown for clarity)) everything is fine! Some how mfg is snarling things >up. > >OK, I just had a brain wave (dont laugh). Here is a diff of the working >eps vs the broken eps... > >diff broken working > >78a79,80 >> %%Page: 1 1 >> bp >229c231 >< 57.60 43.20 403.20 201.60 cl >--- >> 57.60 57.60 403.20 216.00 cl >417c419 >< %%Pages: 0 >--- >> %%Pages: 1 > > >Does that help anyone debug my problem? Like I said, both look identical >via gv, and are 'conceptually' identical in R. > >Here are my vitals > >Linux 2.4.20-31.9 i686 athlon i386 GNU/Linux >R 2.0.0 (2004-10-04). >GNU Ghostscript 7.05 (2002-04-22) > >Anything else you need? > >Please help! > >______________________________________________ >R-help at stat.math.ethz.ch mailing list >https://stat.ethz.ch/mailman/listinfo/r-help >PLEASE do read the posting guide! http://www.R-project.org/posting-guide.html >
Marc Schwartz
2005-Apr-27 01:08 UTC
[Rd] Re: [R] postscript (eps) / latex / par(mfg=...) / problem!
[MOVED TO R-DEVEL] On Tue, 2005-04-26 at 18:05 +0100, Dan Bolser wrote:> Should I post this to 'bugs'?Dan, I suspect part of the problem here is that your code and example were difficult to replicate and there may have been a focus on the page rotation issue, which I think is a red herring here. All below is done with Version 2.1.0 Patched (2005-04-20), which is more recent of course and may reflect an existing problem when using par ("mfg"). mat <- matrix(c(1:14, 16, 20, 23, 24, 26, 28, 886, 792, 136, 201, 16, 58, 6, 21, 3, 9, 3, 9, 1, 4, 3, 1, 1, 1, 1, 1), ncol = 2) colnames(mat) <- c("CHAINS", "FREQUENCY") # Use either the EPS or PDF creation here # Naming the output file based upon the use or non-use # of par("mfg") # Comment the two par("mfg") lines below as appropriate postscript("x.mfg.eps", width = 6, height = 6, horizontal = FALSE, onefile = FALSE, paper = "special") # pdf("nomfg.pdf", width = 5, height = 6) par(mfrow= c(2, 1)) par(mfg = c(1, 1)) par(mar = c(3, 4, 1, 2)) plot(mat, type = "b") par(mfg = c(2, 1)) par(mar = c(4, 4, 0, 2)) plot(mat, type = "b", log = "y") dev.off() What I found, if correct, does not reflect rotation issues with the graphic, but a problem when using par("mfg"), resulting in both EPS and PDF files having a 0 page indication in the resultant file. I have attached EPS and PDF files here named based upon using or not using par ("mfg"). I also used the following LaTeX code to create PS/PDF files as appropriate with curious results. Modify the included graphic file name as appropriate when using it: \documentclass{report} \usepackage{graphicx} \begin{document} \begin{figure} \centering \includegraphics[width=\textwidth]{x.mfg.eps} \caption[X]{Hello!} \label{xFig} \end{figure} \end{document} When using latex and dvips with the x.mfg.eps file, the plot is in the upper left hand corner of the page, very small. Substituting the x.nomfg.eps file, the page looks fine. When using pdflatex with the mfg.pdf file, get the following error: Error: pdflatex (file mfg.pdf): pdf inclusion: required page does not exist <0> ==> Fatal error occurred, the output PDF file is not finished! Trying to open the mfg.pdf file, I get errors from multiple PDF viewers indicating the lack of pages in the file. Interestingly, when opening the EPS files in gv, it seems to happily ignore the 0 page issue and displays the x.mfg.eps file without problem. There are a few other posts in the archive that report problems that were presumed to be the usual rotation issues that Ted refers to in his reply post on r-help. However, when reading them: http://tolstoy.newcastle.edu.au/R/devel/04a/0344.html http://finzi.psych.upenn.edu/R/Rhelp02a/archive/25436.html in both cases, par("mfg") is being used, which is common to Dan's problem here. So, unless I am missing something and without yet delving further into graphic device specific source code, I suspect that there is a problem when creating PS/EPS/PDF files in conjunction with par("mfg"). HTH, Marc Schwartz -------------- next part -------------- A non-text attachment was scrubbed... Name: mfg.pdf Type: application/pdf Size: 7620 bytes Desc: not available Url : https://stat.ethz.ch/pipermail/r-devel/attachments/20050426/718503ea/mfg.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: nomfg.pdf Type: application/pdf Size: 7852 bytes Desc: not available Url : https://stat.ethz.ch/pipermail/r-devel/attachments/20050426/718503ea/nomfg.pdf -------------- next part -------------- A non-text attachment was scrubbed... Name: x.mfg.eps Type: application/postscript Size: 6463 bytes Desc: not available Url : https://stat.ethz.ch/pipermail/r-devel/attachments/20050426/718503ea/x.mfg.eps -------------- next part -------------- A non-text attachment was scrubbed... Name: x.nomfg.eps Type: application/postscript Size: 6478 bytes Desc: not available Url : https://stat.ethz.ch/pipermail/r-devel/attachments/20050426/718503ea/x.nomfg.eps