Despite the refreshing change that the journal PLOS ONE represents in terms of open access and an refreshing change to the stupidity that is quality/novelty selection by the two or three people that review a paper, it’s submission requirements are far less progressive. Yes they make you jump through a lot of hoops getting your figures and tables just so, and I can appreciate why they want some control over this in terms of the look and feel of the journal. A couple of things grate though:
A collection of miscellaneous basic statistic functions and convenience wrappers for efficiently describing data. The author's intention was to create a toolbox, which facilitates the (notoriously time consuming) first descriptive tasks in data analysis, consisting of calculating descriptive statistics, drawing graphical summaries and reporting the results. Since emojifont use showtext as backend to parse emoji font, it also incompatible with RStudio. The solution is to manually open a window by calling X11 in Linux, quartz in Mac or windows in Windows, and create plots on top of that, instead of the built-in device offered by RStudio.
- The insistence on only EPS files as the single acceptable vector-format
- The insistence that Arial be used as the font face in the figures
In this document R refers to the core, command-line-based R system while R.app refers to the GUI-based Mac OS application that controls the underlying R. This `R for Mac OS X FAQ' is rather incomplete at the moment and requires contributions from users. A quartz device is created with a default font (see the documentation for quartz), but it is also possible to specify a font family when drawing to the device (for example, see the documentation for gpar in the grid package). The font family sent to the device is a simple string name, which must be mapped to something more specific to quartz fonts. Quartz.save is a modified version of dev.copy2pdf to copy the plot from the current screen device to a quartz device, by default to a PNG file. Note For a long time the default font family was documented as 'Helvetica' after it had been changed to 'Arial' to work around a deficiency in macOS 10.4.
The choice of EPS is a pain, but can be worked round relatively easily and R can output to an EPS file via the postscript() device, as long as you follow a few basic guidelines, which I’ll cover below. But the use of Arial! facepalm…
Firstly, you may not legally be able to install these fonts on your computer (even though they are available in several forms on the internet) unless you have a licence for a Microsoft product that ships them — though given the dominance of Windows in the consumer PC market, most people will have a valid Windows licence somewhere. Secondly, you need to work very hard to use these fonts in some applications, including R as we’ll see, simply because those applications were built to use different or open font definitions.
What is doubly frustrating about this is that there are entirely free and open fonts that could be mandated by PLOS ONE. The Liberation Fonts suite for example is one such set of fonts, the creation of which was sponsored by Red Hat. The aim was to provide a font that is metric compatible (i.e. the glyphs occupy the same physical space) with Microsoft’s Arial, Times New Roman, and Courier New fonts that are prevalent in the Windows world. The Liberation Fonts aren’t copies of the Microsoft ones, but for a given string, they should occupy the same amount of real estate in the document or on screen. Or PLOS ONE could have stuck with the standard set of Postscript fonts, for which there are free equivalents.
Bob O’Hara raised this issue over a year ago, and Michael Eisen took the time to comment that this was an acknowledged issue and indicated that the problems stemmed from the publishing tools used by PLOS.
Despite the draconian restrictions, PLOS ONE does have a pretty good set of instructions or tips to go alongside them, to help authors prepare figures for the journal. These instructions even include some tips on creating your figures in R with the Arial font family. These instructions basically involve converting the .ttf (TrueType font files) into .afm (Adobe Font Metric) files via the tt2afm utility and subsequently registering the .afm files with R’s postscript() plotting device.
Firstly, the instructions refer to an older way of specifying font families (as a vector paths to four or five .afm files — the fifth file would be for the Symbol font, and if missing R will use the default); there is no reason to presume that R will continue to maintain this backwards-compatible behaviour. Second, they require the user to get and install the tt2afm utility (or some other utility that achieves the same job). Thirdly, the instructions are incomplete if you wish to have the figure reproduce on any system; the fonts need to be embedded for those users that don’t have Arial installed. Admittedly, PLOS ONE’s production system will have these fonts, so that this is missing is irrelevant, but it is something one may need to consider when working with colleagues using a range of OSes.
The new way of referring to font families is a little more convoluted now in modern versions of R. Thankfully, a very simple solution is present that handles the registration of fonts with R’s graphics devices, and as an added bonus will convert .tty font files into the Type1 font equivalents. This solution is Winston Chang’s extrafont package. In the code chunks below, I’ll walk you through installing and using the package to produce a figure suitable for submission to PLOS ONE or any other journal that demands the use of the proprietary Arial font.
First up, install the extrafont package from your local CRAN mirror. For the code below to work, you’ll need version 0.15 or later, which was released to CRAN a few days ago (as of writing). extrafont relies on two additional packages
- extrafontdb contains the font database that extrafont will use. Initially this is an empty package skeleton, but as you’ll see in a minute, it will be populated with the information regarding fonts found on your system that you can use within R graphics devices. The reason this is a separate package is that it won’t get overwritten each time a new version of the main extrafont package is installed. Hence you only need to go through the potentially lengthy process of searching for and converting suitable fonts on system once.
- Rttf2pt1 contains an R wrapper for the
ttf2pt1programme that can convert TrueType fonts into Postscript Type1 fonts, one of the font types that R can use. This is again in a separate package, but this time for licensing reasons. (ttf2pt1is licensed under a 3-clause BSD licence while extrafont is GPL-2 licensed, if this matters to you.)
As all of this is available on CRAN, thanks to Winston and the CRAN maintainers, you can get up and running simply by installing extrafont via
Assuming that the package installs for you then each time you wish to use it, you need to load the package into your R session (as with most other R packages)
The first time you use the package, you will need to register fonts with the extrafont database. This process will search your computer for fonts, register them with the database and convert the font metric information in the .ttf files into .afm equivalents, plus a number of other steps like linking to the .ttf files for the actual glyphs (the .afm files only contain the metrics or size and other metadata for the font, not the individual characters or glyphs, which only live in the .ttf files) to allow font embedding. To initiate this process, run
This can take some time, depending on how many fonts you have installed on your system. However, you only need to do this once (assuming you don’t install fonts regularly) or at the most after you’ve added fonts to your system. You’ll need to confirm the process when asked (just hit y followed by return), and as it is doing its thing, you should see a series of statements printed to the console as each font is found and converted, eg
Once this is finished, you can get a list of fonts it found and registered via the fonts() function
On my system, this returned
Having loaded (or discovered and registered fonts with the system), you need to register the fonts with a particular graphics device. In particular, you need to do this for the pdf() or postscript() devices. For PLOS ONE, you’ll be wanting the postscript() device as that journal requires EPS format files. Here I’ll show both as PDF is generally more useful than EPS when passing figures between colleagues.
The loadfonts() function is used to register fonts and by default it will register them with the pdf() device. The postscript() device can be specified via the device = 'postscript' argument
R will print messages about which fonts have been registered; you can silence this by adding quiet = TRUE to the call to loadfonts().
Now we are in a position to produce a plot and export it from R in PDF or EPS formats. By way of illustration, I’ll use a kernel density estimate (KDE) of the probability density function of the Old Faithful duration between eruption data, available in object faithful (note this is now available without an explicit data() call)
Exporting EPS files via postscript()
To export an EPS file, we use the postscript() device, though to get true EPS output, some additional arguments need to be specified. These are
paper = 'special'onefile = FALSEhorizontal = FALSE
In addition, we need to tell the plot use a particular font family, in this case we use family = 'Arial'. The character value you pass family is one of the entries returned by fonts() (see above). Here is a call that will generate an EPS file of the KDE of the Old Faithful data
Notice that here I use the width = 6.83 (in inches) which corresponds to a 3-column figure in the PLOS One world. Other dimensions for figures can be found on the PLOS ONE Guidelines for Figure and Table Preparation.
Exporting PDF files via pdf()
A similar invocation is required for the pdf() device, but there is no horizontal argument:
Setting up for use on other devices
If a device has a family argument, then you can use the following to open a new device using a given font family (here 'Arial')
This is useful if you want to visualise how the figure will look as you create it. However, it works using the system font provision (on Linux and MacOS X that means Pango), not via extrafont, so do read ?X11, ?windows, or ?quartz for details on how fonts are resolved there.
Embedding fonts
In order for the figure to display properly on any computer with a suitable viewer, the person viewing the file we just generated will need to have Arial installed on their system. Embedding the font (or a subset of glyphs actually used) avoids this situation, at the expense of increased file size. However, embedding fonts with R requires the use of Ghostscript, which needs to be installed. As I mentioned earlier, technically you don’t need this for submission to PLOS ONE, but I include instructions for embedding fonts for completeness.
The extrafont package has a wrapper to the standard embedFonts() function in base R; embed_fonts(). This takes the path to the input EPS file, the path/filename for the outputted file with embedded fonts (this can be missing, in which case the input file is overwritten!), plus a format argument that you can usually ignore (see ?embedFonts for details), and and optional argument options. This options argument is very useful to pass along arguments to the ghostscript programme. On my system, the default ghostscript output device was set to either US Letter or A4 paper, so the EPS figure had a large amount of white space above and to the right of the figure. This needed addressing, obviously and for that I used the EPSCrop argument, which has to be given as you would include it if working with ghostscript directly, hence in the code below I pass -dEPSCrop to the option argument.
Strings For Quartz Font In R Studio For Mac 10 11
Note the PDF file doesn’t need any additional ghostscript arguments so I omit the option argument in that case.
And that is it. Once you’ve set up extrafont and allowed it to search and convert any TrueType fonts on your system, using those fonts is as simple as registering your fonts with a particular device via loadfonts(device = 'foo') (where 'foo' is one of the supported devices; see ?loadfonts), and then specifying the family name of the font when creating the plotting device.
If you have any suggestions for improving these instructions let me know in the Comments; I should pass them along to PLOS ONE at some point so that can add them to their Guidelines for Figure and Table Preparation.
Comments
Please enable JavaScript to view the comments powered by Disqus.comments powered by Disqus
The choice of EPS is a pain, but can be worked round relatively easily and R can output to an EPS file via the postscript() device, as long as you follow a few basic guidelines, which I’ll cover below. But the use of Arial! facepalm…
Firstly, you may not legally be able to install these fonts on your computer (even though they are available in several forms on the internet) unless you have a licence for a Microsoft product that ships them — though given the dominance of Windows in the consumer PC market, most people will have a valid Windows licence somewhere. Secondly, you need to work very hard to use these fonts in some applications, including R as we’ll see, simply because those applications were built to use different or open font definitions.
What is doubly frustrating about this is that there are entirely free and open fonts that could be mandated by PLOS ONE. The Liberation Fonts suite for example is one such set of fonts, the creation of which was sponsored by Red Hat. The aim was to provide a font that is metric compatible (i.e. the glyphs occupy the same physical space) with Microsoft’s Arial, Times New Roman, and Courier New fonts that are prevalent in the Windows world. The Liberation Fonts aren’t copies of the Microsoft ones, but for a given string, they should occupy the same amount of real estate in the document or on screen. Or PLOS ONE could have stuck with the standard set of Postscript fonts, for which there are free equivalents.
Bob O’Hara raised this issue over a year ago, and Michael Eisen took the time to comment that this was an acknowledged issue and indicated that the problems stemmed from the publishing tools used by PLOS.
Despite the draconian restrictions, PLOS ONE does have a pretty good set of instructions or tips to go alongside them, to help authors prepare figures for the journal. These instructions even include some tips on creating your figures in R with the Arial font family. These instructions basically involve converting the .ttf (TrueType font files) into .afm (Adobe Font Metric) files via the tt2afm utility and subsequently registering the .afm files with R’s postscript() plotting device.
Firstly, the instructions refer to an older way of specifying font families (as a vector paths to four or five .afm files — the fifth file would be for the Symbol font, and if missing R will use the default); there is no reason to presume that R will continue to maintain this backwards-compatible behaviour. Second, they require the user to get and install the tt2afm utility (or some other utility that achieves the same job). Thirdly, the instructions are incomplete if you wish to have the figure reproduce on any system; the fonts need to be embedded for those users that don’t have Arial installed. Admittedly, PLOS ONE’s production system will have these fonts, so that this is missing is irrelevant, but it is something one may need to consider when working with colleagues using a range of OSes.
The new way of referring to font families is a little more convoluted now in modern versions of R. Thankfully, a very simple solution is present that handles the registration of fonts with R’s graphics devices, and as an added bonus will convert .tty font files into the Type1 font equivalents. This solution is Winston Chang’s extrafont package. In the code chunks below, I’ll walk you through installing and using the package to produce a figure suitable for submission to PLOS ONE or any other journal that demands the use of the proprietary Arial font.
First up, install the extrafont package from your local CRAN mirror. For the code below to work, you’ll need version 0.15 or later, which was released to CRAN a few days ago (as of writing). extrafont relies on two additional packages
- extrafontdb contains the font database that extrafont will use. Initially this is an empty package skeleton, but as you’ll see in a minute, it will be populated with the information regarding fonts found on your system that you can use within R graphics devices. The reason this is a separate package is that it won’t get overwritten each time a new version of the main extrafont package is installed. Hence you only need to go through the potentially lengthy process of searching for and converting suitable fonts on system once.
- Rttf2pt1 contains an R wrapper for the
ttf2pt1programme that can convert TrueType fonts into Postscript Type1 fonts, one of the font types that R can use. This is again in a separate package, but this time for licensing reasons. (ttf2pt1is licensed under a 3-clause BSD licence while extrafont is GPL-2 licensed, if this matters to you.)
As all of this is available on CRAN, thanks to Winston and the CRAN maintainers, you can get up and running simply by installing extrafont via
Assuming that the package installs for you then each time you wish to use it, you need to load the package into your R session (as with most other R packages)
The first time you use the package, you will need to register fonts with the extrafont database. This process will search your computer for fonts, register them with the database and convert the font metric information in the .ttf files into .afm equivalents, plus a number of other steps like linking to the .ttf files for the actual glyphs (the .afm files only contain the metrics or size and other metadata for the font, not the individual characters or glyphs, which only live in the .ttf files) to allow font embedding. To initiate this process, run
This can take some time, depending on how many fonts you have installed on your system. However, you only need to do this once (assuming you don’t install fonts regularly) or at the most after you’ve added fonts to your system. You’ll need to confirm the process when asked (just hit y followed by return), and as it is doing its thing, you should see a series of statements printed to the console as each font is found and converted, eg
Once this is finished, you can get a list of fonts it found and registered via the fonts() function
On my system, this returned
Having loaded (or discovered and registered fonts with the system), you need to register the fonts with a particular graphics device. In particular, you need to do this for the pdf() or postscript() devices. For PLOS ONE, you’ll be wanting the postscript() device as that journal requires EPS format files. Here I’ll show both as PDF is generally more useful than EPS when passing figures between colleagues.
The loadfonts() function is used to register fonts and by default it will register them with the pdf() device. The postscript() device can be specified via the device = 'postscript' argument
R will print messages about which fonts have been registered; you can silence this by adding quiet = TRUE to the call to loadfonts().
Now we are in a position to produce a plot and export it from R in PDF or EPS formats. By way of illustration, I’ll use a kernel density estimate (KDE) of the probability density function of the Old Faithful duration between eruption data, available in object faithful (note this is now available without an explicit data() call)
Exporting EPS files via postscript()
To export an EPS file, we use the postscript() device, though to get true EPS output, some additional arguments need to be specified. These are
paper = 'special'onefile = FALSEhorizontal = FALSE
In addition, we need to tell the plot use a particular font family, in this case we use family = 'Arial'. The character value you pass family is one of the entries returned by fonts() (see above). Here is a call that will generate an EPS file of the KDE of the Old Faithful data
Notice that here I use the width = 6.83 (in inches) which corresponds to a 3-column figure in the PLOS One world. Other dimensions for figures can be found on the PLOS ONE Guidelines for Figure and Table Preparation.
Exporting PDF files via pdf()
A similar invocation is required for the pdf() device, but there is no horizontal argument:
Setting up for use on other devices
If a device has a family argument, then you can use the following to open a new device using a given font family (here 'Arial')
This is useful if you want to visualise how the figure will look as you create it. However, it works using the system font provision (on Linux and MacOS X that means Pango), not via extrafont, so do read ?X11, ?windows, or ?quartz for details on how fonts are resolved there.
Embedding fonts
In order for the figure to display properly on any computer with a suitable viewer, the person viewing the file we just generated will need to have Arial installed on their system. Embedding the font (or a subset of glyphs actually used) avoids this situation, at the expense of increased file size. However, embedding fonts with R requires the use of Ghostscript, which needs to be installed. As I mentioned earlier, technically you don’t need this for submission to PLOS ONE, but I include instructions for embedding fonts for completeness.
The extrafont package has a wrapper to the standard embedFonts() function in base R; embed_fonts(). This takes the path to the input EPS file, the path/filename for the outputted file with embedded fonts (this can be missing, in which case the input file is overwritten!), plus a format argument that you can usually ignore (see ?embedFonts for details), and and optional argument options. This options argument is very useful to pass along arguments to the ghostscript programme. On my system, the default ghostscript output device was set to either US Letter or A4 paper, so the EPS figure had a large amount of white space above and to the right of the figure. This needed addressing, obviously and for that I used the EPSCrop argument, which has to be given as you would include it if working with ghostscript directly, hence in the code below I pass -dEPSCrop to the option argument.
Strings For Quartz Font In R Studio For Mac 10 11
Note the PDF file doesn’t need any additional ghostscript arguments so I omit the option argument in that case.
And that is it. Once you’ve set up extrafont and allowed it to search and convert any TrueType fonts on your system, using those fonts is as simple as registering your fonts with a particular device via loadfonts(device = 'foo') (where 'foo' is one of the supported devices; see ?loadfonts), and then specifying the family name of the font when creating the plotting device.
If you have any suggestions for improving these instructions let me know in the Comments; I should pass them along to PLOS ONE at some point so that can add them to their Guidelines for Figure and Table Preparation.
Comments
Please enable JavaScript to view the comments powered by Disqus.comments powered by DisqusPosted in
RSocial
Blogroll
- Down With time
- The Contemplative Mammoth
- Dynamic Ecology
- Jabberwocky Ecology
- Recology
- R Bloggers
- Andrew Barr's Ancient Eco
- Methods in Ecology & Evolution
- Musings on Quantitative Palaeoecology
If you just want advice on best practices in RStudio, skip down to here and avoid my rant.
The Good
Projects
One of the excellent things RStudio does is encourage users to define 'projects'and work within the projects. This keeps all the related data and work together in asingle workspace and separates it from other projects you might be working on.Windows users, in particular, that start R by clicking on the icon ontheir desktop often end up with much (or all) of their work in a singleworkspace, commingling work from many potentially different projects. Rof course has facilities to work with separate projects natively, but usersenamored of the desktop often do not use them to full extent. So, RStudioprojects are a good idea. You will certainly want a 'project' for the labspresented in LabDSV, and you might want to separate the labs into separateprojects like 'species modeling', 'ordination', and 'clustering.'Script Editor
RStudio encourages users to work from a script file rather than directly at theconsole. In addition, it provides a text editor for those script files that ismuch superior to generic Wordpad. (Word obviously should never be used to writeR scripts.) As a bonus, the editor can be made to mimic vi, but that's perhapsmoot to most Windows and even Mac users.Tool Tips
When you use the console or script editor window RStudio pops up the command-line version oftool-tips, providing the list of arguments for any function you start to enter.This can be really helpful for commands you're less familiar with and makes itunnecessary to start up the help file just to get the command arguments. Bravofor this innovation.The Bad
Panel Format
By default, RStudio starts up with a four-panel configuration packed into asingle frame. This packaging is very Windowsesque and in my mind impractical.The distribution (and number) of window types within the frame is configurable, and each ofthe windows may have tabs allowing you to select exactly what will appear in thewindow. However, even if you have a large, high resolution monitor the four panel arrangementtries to pack too much into too small a space and results in undesirablecompression of information.Command Redirection
Even if you work in the console, RStudio traps and redirects many simple Rcommands. In particular, I dislike the way it crams R help files into a tinylittle window. Normally,?command will produce a formatted output to theconsole that is easily negotiated with the arrow keys. If you want to stretchout, help.start() pops up the help file system in your browser with fullhot-link capability. It's the same browser with the same capability you'realready familiar with, and you can shrink it or pop it behind your R session to get it out ofthe way when you don't need it. It's a vastly superior solution to the RStudiobox, but RStudio captures the help.start() command and redirects it tothe little box. Bummer.Wasted Space
Some of the little windows are of limited utility and waste space, e.g. theEnvironment, History, Connections window. The information it providesis normally easily printed to the console (if and when you want it) except thatnow RStudio traps those function calls. For example, history(100) willcall up the last 100 commands entered at the console which you can browse andmanage with your arrow keys. You can easily cut-and-paste commands from yourhistory into the console. Instead, in RStudio it redirects the output to thelittle Environment, History, Connections box. Bummer.The Environment, History, Connections window provides theEnvironment tab which gives a summary of objects in yourworkspace. It's more detail than the ls() command provides, but notnearly as much information as str() provides. Clicking on the bluearrow button will provide the str() output, however. Maybe it'shelpful, but ls() and str() in the console provide the sameinformation without taking up real estate on your screen unless you specificallywant to see something.
Data File Import
Importing data into R seems to be a significant problem for many users.Admittedly the plethora of optional arguments for read.table() and theprofusion of read.whatever() functions makes things a littlefunky. You might think that this is one area where a GUI could improve things.Unfortunately, this appears not to be the case.In RStudio there are at least two ways to import data: (1) using the File menu andselecting 'Importing Dataset', or (2) clicking on a file in the File tab in the'Files, Plots, Etc' panel. Unfortunately (maybe deliberately?) they do thingsdifferently. The File menu approach first pops up a list of import formatoptions. Notably, it offers a choice between 'From text (base) ...' and 'FromText (readr) ...' This is important because base and readrdiffer significantly in the data formatting they support. If you choose 'Fromtext (base)' you get a file chooser. Selecting a file opens the import GUI withoptions to the left, a file previewer to the top right, and a data.framepreviewer to the bottom right. This part is nice. Unfortunately, it doesn'toffer a code preview of the R function that will ultimately be called to do theimport. After clicking on 'Import' you can see in the console that it usesread.table. Importantly, it offers options for choosing or settingrow.names() and a box to click for 'stringsAsFactors'. It follows theread.table() protocol that if the first row has one fewer entries thanthe rest of the lines then the first line is assumed to be a header with columnnames. It offers a fairly limited set of separators (e.g not including |), butis otherwise fairy flexible and functional.
The second option (clicking on a file name in the File panel) is quitedifferent. First, it only offers the option to import files with a limitednumber of file extensions (maybe just .csv?). Files with .dat or .txt extensionscannot be imported. Second, even if package readr is not loaded, it'sfirst choice is to load readr and then use read_csv(). Forexample, for a file called test.csv, it provides a 'Code Preview' that lookslike
There doesn't seem to be an option to choose (base) read.table(), butyou can edit the Code Preview and change whatever you like. To the lower left isa panel with options to select. This time, the Delimiter dropdown menu offers'other' and you can specify '|' for example, which automatically changes theCode Preview to use read_delim() instead of read_csv.Unfortunately, read_delim() seems incapable of reading files where thefirst line has fewer entries than the rest of the lines. The previewer gives nowarning (although you can see the headings are misaligned if you look). Whenyou click 'Import', however, the console fills with error messagesending with
That's a fairly cryptic error message for a parsing failure, but the materialthat comes before that is somewhat more helpful. Curiously, despite the copiouserror messages it does not abort the import and happily reads the data into thewrong columns, pruning off the last column of data instead of manufacturing acolumn heading for the last column. As far as I know, this is standard behaviorfor readr functions, but it's disturbing.
Since read_delim() is a readr function, it returns a tibbleinstead of a data.frame whether that's what you want or not. I STRONGLY advise against using tibbles in LabDSV; row.names are critical and tibbles often mangle them. There is obviously more to say, but I'll leave it for the moment.
If you're really stubborn, you can edit the code in the Code Preview window to dowhat you want, but every time you touch something in the options panel RStudiowill rewrite the Code Preview window to its liking. Frankly, it's much easierto use the console.
The Ugly
Ridiculous Graphics
RStudio totally hoses the outstanding graphics capabilities of R. By default, in RStudiographics get plotted to a little window in a box that is much too small to allowfor a decent font or resolution. It's cramped and ugly. Worse yet, it decides on the X and Y limits depending on the size and shape of that little box. There is an option to'zoom' the plot, which produces another re-sizable graphics window. The windowis re-sizable, but it's not possible to specify an actual dimension or fontpoint size so that it's difficult to simulate a graphic you would include in alab report or publication. ?RStudioGD offers no help.Much worse, from the perspective of LabDSV, while you can resize it (with'automatic' font and glyph size re-scaling) you cannot interact with the zoomedwindow; you still have to precisely identify points in the tiny window. You can(and generally have to) resize the box (at the expense of the console and scripteditor) to actually see what you're doing. Equally bad, it doesn't render thepoints as you draw (just pops up a stupid blue bubble), and you can't see whatyou have drawn until you click 'finish' or 'ESC'. It's ridiculously easy tomake mistakes, and if you do, all you can do is start over. RStudio usersshould avoid the RStudioGD graphics device like the plague.
Worse yet, in my mind, it only offers you a single window. It stores all ofyour plots and you can recall them later if you want, but you can't put twoplots up side-by-side to compare. You can do par(mfrow=(1,2)) to gettwo plots side-by-side, but now their aspect ratios are squished and ridiculousuntil you resize the box again at the expense of the console and script editor windows. It's difficult to switch back and forth btween them and interact withthem. It's lame.
I routinely have two or three graphics windows open with specified sizes, fontsizes and families. I can pop them to the front or back with the window managerand put them side-by-side or atop each other easily. It's beautiful.
The Script Editor
As I noted above, providing a built-in script editor is arguably a good idea,especially if you're stuck using Windows. If I had to use someone else's Windowscomputer that lacked a decent text editor I would undoubtedly be delighted tohave the one inside RStudio.While in exploratory mode I generally use R directly from the console. Encouragingusers to write reproducible scripts is a good idea as their work matures.However, I insist 'It's only a script if you source it.' Instead, whatI observe is that students enter all their interactive coding into the scriptwindow, as opposed to the console, and then highlight specific lines and clickon 'Run' to get it transferred down to the console. It's not just that it'sinefficient (and it is, just type the command in the freakin console), it leadsto horrible habits. The script window code gives the impression of a specificorder of execution, but when you just highlight random lines and click on 'Run'you have no real order of operation. You could easily highlight the same linetwice and get different results because you have executed other commands in themeantime. Now arguably this is user error and not RStudio's fault, but it should be impossibleto execute specific commands without re-executing all lines in the script thatprecede that line. So, instead of a script, at best the script editor becomes acloset of R code, and at worst a junk drawer of R code. It's dangerous.
The Insufferable
Window Manager
RStudio insists on managing your Windows according to its own rules. On mycomputer, to cut-and-paste I use the first and second mouse buttons with no needto use the keyboard. In RStudio to transfer code from the console to thescript window I have to use the heinous CTRL-C/CTRL-V mantra. Worse, on my computer Iuse 'focus follows Mouse.' I.e., whatever window my mouse cursor is in gets focus andI don't have to click in the window to get the old one to let go and get the newone to pay attention. Having to click in a window before you can type in it islike having to punch somebody in the nose before you can talk to them; it'sviolent and unnecessary. And it's infuriating when you are constantly typing inthe wrong window after deliberately moving the cursor to the window you want.Students have heard many an expletive from me when I have to work on Windows,and RStudio does its damnedest to convert my linux machine to Windows.Command Redirection
In R I can generally execute the system() command to get to the shellinterpreter and execute miscellaneous commands. In RStudio I can sometimes dothat, i.e. system('ls -l') works and gives a list of files from mycurrent directory in the console. On the other hand, something as simple assystem('more filename.txt')Strings For Quartz Font In R Studio For Mac Serial
crashes RStudio and you lose all your work.It's unforgivable. There is a separate 'terminal' tab in the console windowthat allows interaction with the system, but it's another unnecessary nuisancein using RStudio.Script Editor and fix()
In R you can enter fix(function_name)and pop up an editing session withthe editor of your choice. When you are done, you exit the editor and it savesa copy of your function into your current workspace. If you are comfortable inyour editor it's a Godsend. In RStudio, if you enterfix(function_name) it pops up a ridiculous little postage stamp of aneditor and completely ignores your choice of editor. Even though I specified viemulation in the script editor the fix() editor ignores that and givesme some primitive editing functions. To further theaggravation, the window is not re-sizable, but rather offers a horizontalscrolling bar if your text is wider than some small number of characters. Give me a break!Instead, you have to use the script editor (even though you're writing afunction, not a script). When you're done, however, you can't just enter theexit command and save the function to your workspace. You can write it to a filewith the 'Source on Save' box ticked, or you can highlight all the lines and click on the Run button. However, that saves the whole thing to your consoleone line at a time, scrolling off anything else you were interested in and cloggingup your .Rhistory file unnecessarily. It's lame.
Best Practices in RStudio
If you find that RStudio provides a better way to interact with R then by allmeans make use of it. However, I strongly suggest the following:- Do NOT import data using the RStudio file-based data import tool. It will hose your data and make your life miserable. The drop-down menu allows .read.table()and is semi-functional but certainly no better then the console.
- Take your mouse, grab the vertical bar separating the script window andconsole from the other two windows and push the bar all the way to the right toeliminate the 'Environment, History, Connections' and 'Files, Plots, etc'windows. You can always get them back if you want, but get them out of theway.
- Click in the console window, and enter x11() to pop up a floatinggraphics window to plot to. If you're on a Mac, enter quartz().As I noted above, you can specify a specific window sizeand font point size and family if you prefer. Enter the command more than once if you want to do side-by-side comparisons or have multiple plots visible at the sametime. The windows will get numbered (starting with 2) and you can specify whichwindow is the current device with dev.set(2) for example.
- If you're not actually writing a script intended to be run from the first lineto the last, enter your commands directly in the console, not the scripteditor. Don't worry, you have permission to enter text there; it doesn't belongto RStudio exclusively. The order of operation is saved to the .Rhistoryfile so you know exactly what you have done. Later, you can easily edit the .Rhistoryfile into a script if desired.
