Defaults for postscript()
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>