The defaults for postscript()
paper = "default"
onefile = TRUE
horizontal = TRUE
(it seems) date from the days when people used to used this to send plots
directly to a postscript printer via print.it=TRUE. I haven't done that
for years, and it seems that our current generation of students don't even
know the concept. It seems 'horizontal = TRUE' is particularly difficult
to grasp.
Given that I suspect almost all uses of postscript() are to produce plots
to be viewed on-screen or incorporated into another document, a more
appropriate set of defaults would be
width = 7, height = 7
paper = "special"
onefile = FALSE
horizontal = FALSE
which would have the advantage of using the same default aspect ratio for
plots as all (?) other R graphics devices.
Does anyone see a reason not to change the defaults?
Brian D. Ripley, ripley at 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
On 12/6/07, Prof Brian Ripley <ripley at stats.ox.ac.uk> wrote:
The defaults for postscript()
paper = "default"
onefile = TRUE
horizontal = TRUE
(it seems) date from the days when people used to used this to send plots
directly to a postscript printer via print.it=TRUE. I haven't done that
for years, and it seems that our current generation of students don't even
know the concept. It seems 'horizontal = TRUE' is particularly difficult
to grasp.
Given that I suspect almost all uses of postscript() are to produce plots
to be viewed on-screen or incorporated into another document, a more
appropriate set of defaults would be
width = 7, height = 7
paper = "special"
onefile = FALSE
horizontal = FALSE
which would have the advantage of using the same default aspect ratio for
plots as all (?) other R graphics devices.
Does anyone see a reason not to change the defaults?
I'm not so sure about the 'onefile' change. Scripts with multiple
plots run in batch mode will end up with multiple files; I prefer the
current behaviour. I also have test scripts in packages that go
postscript("something.ps")
<many examples>
dev.off()
Unless I change all these to have onefile=TRUE, I'll end up only with
the last plot available after the tests are run.
-Deepayan
On Thu, 2007-12-06 at 00:32 -0800, Deepayan Sarkar wrote:
On 12/6/07, Prof Brian Ripley <ripley at stats.ox.ac.uk> wrote:
The defaults for postscript()
paper = "default"
onefile = TRUE
horizontal = TRUE
(it seems) date from the days when people used to used this to send plots
directly to a postscript printer via print.it=TRUE. I haven't done that
for years, and it seems that our current generation of students don't even
know the concept. It seems 'horizontal = TRUE' is particularly difficult
to grasp.
Given that I suspect almost all uses of postscript() are to produce plots
to be viewed on-screen or incorporated into another document, a more
appropriate set of defaults would be
width = 7, height = 7
paper = "special"
onefile = FALSE
horizontal = FALSE
which would have the advantage of using the same default aspect ratio for
plots as all (?) other R graphics devices.
Does anyone see a reason not to change the defaults?
I'm not so sure about the 'onefile' change. Scripts with multiple
plots run in batch mode will end up with multiple files; I prefer the
current behaviour. I also have test scripts in packages that go
postscript("something.ps")
<many examples>
dev.off()
Unless I change all these to have onefile=TRUE, I'll end up only with
the last plot available after the tests are run.
-Deepayan
In a vacuum, I would agree that changing the default values makes sense
given the preponderance of the use for postscript() for creating EPS
files for use in LaTeX and other documents (eg. Office/OO.org). It might
also serve to reduce the frequency of questions on the lists on this
subject.
That being said, I understand Deepayan's concern.
I don't have a sense of how many others would be affected by such a
change.
Pending any other comments on the matter, an incremental approach might
include an initial near term restructuring of the help file for
postscript(), whereby the following content in the Details section:
The postscript produced for a single R plot is EPS (Encapsulated
PostScript) compatible, and can be included into other documents, e.g.,
into LaTeX, using \includegraphics{<filename>}. For use in this way you
will probably want to set horizontal = FALSE, onefile = FALSE, paper =
"special". Note that the bounding box is for the device region: if you
find the white space around the plot region excessive, reduce the
margins of the figure region via par(mar=).
is moved to a new Notes section, which could precede the Details
section, given the likely nature of such use. This change could be done
now for R-patched and R-devel.
A separate second comment could be added to the Notes section,
indicating that the defaults will change to those above in version
2.8.0. The longer time frame would give affected package maintainers a
heads up of the pending change and more lead time for implementation of
any changes.
HTH,
Marc
The defaults for postscript()
paper = "default"
onefile = TRUE
horizontal = TRUE
(it seems) date from the days when people used to used this to send plots
directly to a postscript printer via print.it=TRUE. I haven't done that
for years, and it seems that our current generation of students don't even
know the concept. It seems 'horizontal = TRUE' is particularly difficult
to grasp.
Given that I suspect almost all uses of postscript() are to produce plots
to be viewed on-screen or incorporated into another document, a more
appropriate set of defaults would be
width = 7, height = 7
Wouldn't that be better as width = 6, height = 6 to match pdf() ?
Paul
paper = "special"
onefile = FALSE
horizontal = FALSE
which would have the advantage of using the same default aspect ratio for
plots as all (?) other R graphics devices.
Does anyone see a reason not to change the defaults?
Dr Paul Murrell
Department of Statistics
The University of Auckland
Private Bag 92019
Auckland
New Zealand
64 9 3737599 x85392
paul at stat.auckland.ac.nz
http://www.stat.auckland.ac.nz/~paul/
The defaults for postscript()
paper = "default"
onefile = TRUE
horizontal = TRUE
(it seems) date from the days when people used to used this to send plots
directly to a postscript printer via print.it=TRUE. I haven't done that
for years, and it seems that our current generation of students don't even
know the concept. It seems 'horizontal = TRUE' is particularly difficult
to grasp.
Given that I suspect almost all uses of postscript() are to produce plots
to be viewed on-screen or incorporated into another document, a more
appropriate set of defaults would be
width = 7, height = 7
Wouldn't that be better as width = 6, height = 6 to match pdf() ?
Perhaps (but not matching X11 nor windows). Would anyone notice the
difference? One argument against is that I now think the default
pointsize in pdf() is too large for the default device region.
I would have suggested 8x6 (which is what the MASS scripts use) apart from
the R preference for square device regions.
Thanks to Deepayan & Marc for other comments: I will have some follow-up
comments in due course.
Paul
paper = "special"
onefile = FALSE
horizontal = FALSE
which would have the advantage of using the same default aspect ratio for
plots as all (?) other R graphics devices.
Does anyone see a reason not to change the defaults?
Brian D. Ripley, ripley at 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
On 06/12/2007, Marc Schwartz <marc_schwartz at comcast.net> wrote:
On Thu, 2007-12-06 at 00:32 -0800, Deepayan Sarkar wrote:
On 12/6/07, Prof Brian Ripley <ripley at stats.ox.ac.uk> wrote:
The defaults for postscript()
paper = "default"
onefile = TRUE
horizontal = TRUE
(it seems) date from the days when people used to used this to send plots
directly to a postscript printer via print.it=TRUE. I haven't done that
for years, and it seems that our current generation of students don't even
know the concept. It seems 'horizontal = TRUE' is particularly difficult
to grasp.
Given that I suspect almost all uses of postscript() are to produce plots
to be viewed on-screen or incorporated into another document, a more
appropriate set of defaults would be
width = 7, height = 7
paper = "special"
onefile = FALSE
horizontal = FALSE
which would have the advantage of using the same default aspect ratio for
plots as all (?) other R graphics devices.
Does anyone see a reason not to change the defaults?
I'm not so sure about the 'onefile' change. Scripts with multiple
plots run in batch mode will end up with multiple files; I prefer the
current behaviour. I also have test scripts in packages that go
postscript("something.ps")
<many examples>
dev.off()
Unless I change all these to have onefile=TRUE, I'll end up only with
the last plot available after the tests are run.
-Deepayan
In a vacuum, I would agree that changing the default values makes sense
given the preponderance of the use for postscript() for creating EPS
files for use in LaTeX and other documents (eg. Office/OO.org). It might
also serve to reduce the frequency of questions on the lists on this
subject.
That being said, I understand Deepayan's concern.
I don't have a sense of how many others would be affected by such a
change.
Pending any other comments on the matter, an incremental approach might
include an initial near term restructuring of the help file for
postscript(), whereby the following content in the Details section:
The postscript produced for a single R plot is EPS (Encapsulated
PostScript) compatible, and can be included into other documents, e.g.,
into LaTeX, using \includegraphics{<filename>}. For use in this way you
will probably want to set horizontal = FALSE, onefile = FALSE, paper =
"special". Note that the bounding box is for the device region: if you
find the white space around the plot region excessive, reduce the
margins of the figure region via par(mar=).
I would like to suggest the following wrapper:
eps <- function(file="Rplot%03d.eps", horizontal=FALSE, paper="special", ...) {
postscript(file=file, onefile=FALSE, horizontal=horizontal, paper=paper, ...);
}
That separates the use case of creating EPS files and "regular"
postscript files allow each of eps() and postscript() to have their
own default values.
/Henrik
is moved to a new Notes section, which could precede the Details
section, given the likely nature of such use. This change could be done
now for R-patched and R-devel.
A separate second comment could be added to the Notes section,
indicating that the defaults will change to those above in version
2.8.0. The longer time frame would give affected package maintainers a
heads up of the pending change and more lead time for implementation of
any changes.
HTH,
Marc
I am trying to cross compile R-2.6.0 for ARM. I have my cross compiling
tool chain set up already.
I've read the cross compiling guide for WIN
# http://cran.r-project.org/doc/contrib/cross-build.pdf
# http://cran.r-project.org/doc/contrib/Makefile-rcb
Following the same approach, I compiled the native R-2.6.0 version
first. Then passed R=R-2.6.0 to ./configure. After that, I hacked
makefiles to set R_EXE to the native R binary.
I was able to compile through until R packages in /src/library, where
the following command was issued
$R_EXE --vanilla --slave -f /src/library/base/makebasedb.R
| Error in eval(expr, envir, enclos) :
| may already be using lazy loading on base
| Calls: local -> eval.parent -> eval -> eval -> eval -> eval
| Execution halted
Seems the error was caused by lazy loading mechanism of the native R
binary on the host. AFAIK --vanilla should suppress loading any package
upon startup, however, seems there is no way to get around lazy loading.
My questions are why cross compiling for WIN don't hit this error (maybe
some special setting I'm not aware of was set in the makefile for WIN).
Second, how could I get around this lazy loading issue, if my approach
is not completely off?
Thanks
Gordon
I think everyone who commented has overlooked that the defaults for these
postscript() arguments are set by ps.options(), so in fact we are talking
about the defaults for the defaults. Unfortunately, the documentation on
this was full of errors, including not pointing out that some of the
ps.options() settings apply to xfig() and pdf() (and some do not).
In fact, although you can set the default for 'onefile' via ps.options(),
that setting is never used AFAICS.
This means that it was never completely safe to rely on the defaults in
test scripts in packages, since a site could change these defaults
(although hopefully it would have been done in a file skipped by
--vanilla).
Given that (most of) the defaults are customizable, it does seem to me to
be much more important to have defaults that are appropriate to the naive
user and not the expert one. When I first drafted this, I thought one
could switch between the old and proposed defaults via a call to
ps.options(), but despite documenting 'onefile' as an argument, it is
never actually used.
I had a further follow-up suggestion, which is to change the default
device in non-interactive use from postscript() to pdf(). I believe that
PDF viewers are more widely available than PS viewers these days (almost
every Windows box ships with AcroRead, and Mac OS has native PDF viewers).
There used to be an argument over the non-availability of Free PDF viewers
and the limited range of platforms supported by AcroRead, but the
availability of several viewers based on xpdf seem to satisfy that
argument at least as well as the availability of ghostscript and
front-ends do for PS (and GSView, the Windows front-end, is shareware-like
- I keep forgetting that, as Oxford has a site licence).
I remain convinced that producing rotated PS plots of a size (and aspect
ratio) that depends on the locale (since the default papersize does) is no
longer a reasonable default.
That leaves onefile=TRUE. Even if we don't move the non-interactive
default device to pdf, it could be postscript(onefile=TRUE). However, it
ought to be possible to implement onefile=NA, which would write an EPS
file if only one plot was produced and a multi-page PS file otherwise.
That would seem to me to be a good compromise.
Comment to Marc Schwartz: we can't force a Notes sections above Details,
as the ordering of sections is dictated by Rdconv. I had already done
some re-structuring of the page, moving printing to a new section.
A further comment: I wonder if we really want this complexity of using
ps.options() to set default defaults: I am inclined to remove it for xfig
and pdf. (Given that it was not documented, it is unlikely anyone is
knowingly used it.)
On Thu, 6 Dec 2007, Deepayan Sarkar wrote:
On 12/6/07, Prof Brian Ripley <ripley at stats.ox.ac.uk> wrote:
The defaults for postscript()
paper = "default"
onefile = TRUE
horizontal = TRUE
(it seems) date from the days when people used to used this to send plots
directly to a postscript printer via print.it=TRUE. I haven't done that
for years, and it seems that our current generation of students don't even
know the concept. It seems 'horizontal = TRUE' is particularly difficult
to grasp.
Given that I suspect almost all uses of postscript() are to produce plots
to be viewed on-screen or incorporated into another document, a more
appropriate set of defaults would be
width = 7, height = 7
paper = "special"
onefile = FALSE
horizontal = FALSE
which would have the advantage of using the same default aspect ratio for
plots as all (?) other R graphics devices.
Does anyone see a reason not to change the defaults?
I'm not so sure about the 'onefile' change. Scripts with multiple
plots run in batch mode will end up with multiple files; I prefer the
current behaviour. I also have test scripts in packages that go
postscript("something.ps")
<many examples>
dev.off()
Unless I change all these to have onefile=TRUE, I'll end up only with
the last plot available after the tests are run.
-Deepayan
Brian D. Ripley, ripley at 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
On Tue, 2007-12-11 at 10:30 +0000, Prof Brian Ripley wrote:
I think everyone who commented has overlooked that the defaults for these
postscript() arguments are set by ps.options(), so in fact we are talking
about the defaults for the defaults. Unfortunately, the documentation on
this was full of errors, including not pointing out that some of the
ps.options() settings apply to xfig() and pdf() (and some do not).
In fact, although you can set the default for 'onefile' via ps.options(),
that setting is never used AFAICS.
That actually sounds familiar. I think that I ran into that a few years
ago when I was writing some reports and attempted to use that option.
Yep, checking my svn files, I found the following comment:
# Set ps.options() for most, though postscript() will override the
# onefile = FALSE.
ps.options(horizontal = FALSE, paper = "special",
width = 9.5, height = 7.5)
...
Apparently, for whatever reason, I did not pursue it further...seems
contrary to my usual dive in with both arms and feet paradigm... :-)
This means that it was never completely safe to rely on the defaults in
test scripts in packages, since a site could change these defaults
(although hopefully it would have been done in a file skipped by
--vanilla).
Given that (most of) the defaults are customizable, it does seem to me to
be much more important to have defaults that are appropriate to the naive
user and not the expert one. When I first drafted this, I thought one
could switch between the old and proposed defaults via a call to
ps.options(), but despite documenting 'onefile' as an argument, it is
never actually used.
I do agree here that given the catalyst for considering these changes,
it seems appropriate to focus on ease of use, which in this case, would
need not come at the expense of flexibility.
Within that context, I do rather fancy Henrik's suggestion of an eps()
wrapper to postscript:
https://stat.ethz.ch/pipermail/r-devel/2007-December/047658.html
though I might be tempted to further constrain the function prototype
to:
eps <- function(file = "Rplot%03d.eps", height = 6, width = 6, ...) {
postscript(file = file, onefile = FALSE, horizontal = FALSE,
height = height, width = width, paper = "special", ...)
}
given the most common use of eps files. That still leaves the native
postscript() function available for additional customization as
required, including using ps.options().
I had a further follow-up suggestion, which is to change the default
device in non-interactive use from postscript() to pdf(). I believe that
PDF viewers are more widely available than PS viewers these days (almost
every Windows box ships with AcroRead, and Mac OS has native PDF viewers).
There used to be an argument over the non-availability of Free PDF viewers
and the limited range of platforms supported by AcroRead, but the
availability of several viewers based on xpdf seem to satisfy that
argument at least as well as the availability of ghostscript and
front-ends do for PS (and GSView, the Windows front-end, is shareware-like
- I keep forgetting that, as Oxford has a site licence).
This seems reasonable for all of the reasons referenced. Even for LaTeX
use, unless one is using PS specific packages (eg. pstricks, which I
tend to use for diagrams, etc.), using pdflatex seems more common for
new users.
I remain convinced that producing rotated PS plots of a size (and aspect
ratio) that depends on the locale (since the default papersize does) is no
longer a reasonable default.
That leaves onefile=TRUE. Even if we don't move the non-interactive
default device to pdf, it could be postscript(onefile=TRUE). However, it
ought to be possible to implement onefile=NA, which would write an EPS
file if only one plot was produced and a multi-page PS file otherwise.
That would seem to me to be a good compromise.
My initial reaction is that this approach would seem to make things more
difficult from a maintenance/documentation standpoint, but perhaps I am
missing something.
Comment to Marc Schwartz: we can't force a Notes sections above Details,
as the ordering of sections is dictated by Rdconv. I had already done
some re-structuring of the page, moving printing to a new section.
I noted that in svn. Thanks.
A further comment: I wonder if we really want this complexity of using
ps.options() to set default defaults: I am inclined to remove it for xfig
and pdf. (Given that it was not documented, it is unlikely anyone is
knowingly used it.)
Again, seems reasonable. I would tend to favor parsimony here.
Thanks!
Marc
<snip>
I think you should change anything you want to change, on the assumption that
most users are setting things by themselves, anyway.
Now may be the time to change anything that you (and those kind enough to
reply to your post) would like to see changed. For an example, I really
like the ratio of font size to default plot size that I see in windows on my
OSX machine, and would love it if pdf (which I use instead of postscript),
produced similar geometry. I find pdf() produces a sort of "spaced out"
appearance, with large fonts and lots of spacing, and that's great for
giving lectures, but for papers I always set the page width to 10 inches or
more, simply to get a higher ratio of data to labels.