TikZ can produce output that is friendly for both plain TeX and ConTeXt. Look into supporting these systems.

On some systems, systems calls to latex return warnings of a non-zero exit status since we use \@@end to stop the process. Warnings look like:

running command '/usr/texbin/latex -interaction=batchmode -output-directory /var/folders/Qs/Qs80pcjVHlm3bMdyHfy2W++++TI/-Tmp-//RtmpK8pfqt /var/folders/Qs/Qs80pcjVHlm3bMdyHfy2W++++TI/-Tmp-//RtmpK8pfqt/tikzStringWidthCalc.tex 2>/dev/null' had status 1

R CMD CHECK is throwing warning messages on CRAN for the Solaris operating system. This is the explanation and bug report from Brian Ripley:

It looks like you have not consulted the Value section of the current help page for Sys.which:

Value:

A character vector of the same length as ‘names’, named by
‘names’. The elements are either the full path to the
executable/script or some indication that no executable of that
name was found. Typically the indication is ‘""’, but this does
depend on the OS (and is a message on Solaris).

So you need an additional check that the result actually is a command (e.g. via file.exists).

Can we please have an update addressing this.

(It is likely that Sys.which will be changed in future to incorporate this check, but package changes are still needed to work with current and earlier versions of R.)

It would be nice if detailed error is presented to end user instead of generic one. I copy/pasted part of my pgfSweave document and forgot that I specified prefix.string option with folder in it. It took me a while to realize that I don't have output folder for tikz result.

Error in tikzDevice::tikz(file = paste(chunkprefix, "tikz", sep = "."), :
TikZ device setup was unsuccessful!

Grid-based graphics tend to produce tons of useless clipping (that is, clipping scopes within which nothing is drawn). Even just calling grid.newpage by itself...

suppressPackageStartupMessages({
  library(tikzDevice)
  library(grid)
})
tikz("grid1.tex", standAlone=TRUE, width=2, height=2)
grid.newpage()
invisible(dev.off())

produces a picture environment containing two useless empty clipping scopes:

\begin{tikzpicture}[x=1pt,y=1pt]
\definecolor[named]{drawColor}{rgb}{0.00,0.00,0.00}
\definecolor[named]{fillColor}{rgb}{1.00,1.00,1.00}
\fill[color=fillColor,fill opacity=0.00,] (0,0) rectangle (144.54,144.54);
\begin{scope}
\path[clip] (  0.00,  0.00) rectangle (144.54,144.54);
\end{scope}
\begin{scope}
\path[clip] (  0.00,  0.00) rectangle (144.54,144.54);
\end{scope}
\end{tikzpicture}

Doing anything more complicated can produce dozens of these useless clips: for instance, the output of

library(ggplot2)
tikz("grid1.tex", standAlone=TRUE, width=2, height=2)
qplot(1, 1, geom="point")
invisible(dev.off())

contains 157 of them.

This is, strictly speaking, grid's fault rather than tikzDevice's, but I can imagine that it might be easier to fix at the device level. Bonus points for also eliminating clipping paths that are useless not because nothing is drawn, but because everything that is drawn is strictly inside the clip.

It would be nice to store the log files of failed runs in a list, say the last 5 bad ones. Then instead of dumping pages of text to the console, we would just print an error message and say something like "run tikz_showlog to see the logfile".

This could also be extended to keeping every log if the device is built in debug mode which would help with package development.

The tikz testsuite is getting a little bit long in the tooth. Specifically, two issues related to R 2.12.x should have been caught by the testsuite which would have removed the need for a 0.5.3 release:

• The test suite does not create it's own metrics dictionary that is separate from the user's normal dictionary. This prevented testsuite metrics from being recalculated which ment that the developers never noticed all the new warning messages R 2.12.0 was spewing.
• The testsuite does a good job of checking to see that the tikzDevice works the way it should. However, it does not check to see that the tikzDevice fails the way it should. A check for failure could have shown that error messages were not being generated when they should have been.

Proposal:

Migrate the test scripts to a unit testing framework, such as Hadley's test_that.

Benefits:

• test_that provides excellent capabilities for isolating tests so that the actions and results of one test do not affect the execution of another test.
• test_that contains failure checks. Tests can be designed to fail and the framework checks to see that the expected error/warning message is generated.

Comments?

The footer text passed to tikz is never inserted into the output. Don't know if we ever used the footer since the text wasn't even properly stored at the C level until commit df8b27b.

Anyway, since this is an advertised option, it should be actually implemented.

As reported by Baptiste Auguie:

A simple plot of several lines with various thicknesses using grid graphics:

require(grid)
require(tikzDevice)

tikz('line_width.tex', standAlone = TRUE)
plot.new()
segments(0,seq(-1,1,by=0.2),1,seq(-1,1,by=0.2),lwd=seq(0.2,by=0.2,length=11))
dev.off()

Produces output with far less variation in line thickness than the lwd parameter would suggest:

\draw[color=drawColor,line cap=round,line join=round,fill opacity=0.00,] ( 65.18,  2.61) -- (464.71,  2.61);

\draw[color=drawColor,line cap=round,line join=round,fill opacity=0.00,] ( 65.18, 75.85) -- (464.71, 75.85);

\draw[color=drawColor,line cap=round,line join=round,fill opacity=0.00,] ( 65.18,149.09) -- (464.71,149.09);

\draw[color=drawColor,line cap=round,line join=round,fill opacity=0.00,] ( 65.18,222.33) -- (464.71,222.33);

\draw[color=drawColor,line cap=round,line join=round,fill opacity=0.00,] ( 65.18,295.56) -- (464.71,295.56);

\draw[color=drawColor,line width= 0.8pt,line cap=round,line join=round,fill opacity=0.00,] ( 65.18,368.80) -- (464.71,368.80);

\draw[color=drawColor,line width= 0.8pt,line cap=round,line join=round,fill opacity=0.00,] ( 65.18,442.04) -- (464.71,442.04);

The parameter values passed to TikZ_Line in plotParams->lwd are:

1.0000
1.2000
1.4000
1.6000
1.8000
2.0000
2.2000

Reported in issue 15. Apparently only happens when Sweave is invoked from Rgui or Rscript.

Appears to be related to the creation of temporary metrics dictionaries:

5 : echo term verbatim tikz sanitize (label=mv_fig) 
Creating temporary TikZ metrics dictionary at:

    C:\DOCUME~1\user\LOCALS~1\Temp\Rtmp52vg3A/tikzMetricsDictionary

Error: no function to return from, jumping to top level
Execution halted

Files to reproduce located at:

http://www.sendspace.com/file/obbg5h

EDIT: Changed the name of the issue because it is not specific to Sweave

Running the entire graphics testsuite can be a pain when you just want to see if a given category of graphs is broken or fixed yet. Waiting for all the other graphs to run is a waste of time.

Should be easy to do by adding a tag field to the test structure and running the test list through Filter in test_graphics.R:

if (!is.null(tags_to_test)) {
  test_graphs <- Filter(function(graph){any(graph$tags %in% tags_to_test)}, test_graphs)
}

Where tags_to_test could be a list of tags specified on the command line.

Use ImageMagick's compare utility to check the results of the testsuite against a "control" PDF that we know is a correct version of the test graph. This way, if we break some metric calculation or drawing routine compare will notice a large difference and flag the test as failed. This addition would also mean that the results of the testsuite don't have to be manually inspected before a release to see if something went funky.

The C code in the tikzDevice has grown rather organically over the last few releases and lots of things have simply been dumped into it. The code should be reviewed to ensure comments are still valid, reorganized to make sure functions are laid out in a logical order and possibly improved by combining/eliminating unused or duplicated functions and replacing some common operations with Preprocessor macros.

A good target for replacement by a macro would be the operation that grabs the tikzDevice namespace:

#define TIKZ_NAMESPACE eval(lang2(install("getNamespace"), mkString("tikzDevice")), R_GlobalEnv)

The example of using bareBones in the Vignette is pretty uninspiring. If I recall, it was added at the eleventh hour before the first version shipped just to get something in there.

I have a better example from my capstone project that uses tikzAnnotate to insert named coordinates into the plot of a map and then includes the resulting bareBones output into a larger TikZ image that attaches labels and arrows to the coordinates. Something like this would be a lot better than the lame Brownian Motion example (it is still impressive that TIkZ can enable TeX to calculate a Brownian though).

There is a .net in the address of r-forge when it should be .org. So:

install.packages( 'tikzDevice',
repos='http://r-forge.r-project.org' )

It would be nice to drop coordinates and annotations into grid graphics. For base graphics, the grconvertX and grconvertY functions are used. However, grid graphics are a bit different because the actual location of a point is unknown until it is rendered to a viewport --- not technically true, locations in a viewport are unknown until it is pushed to a graphics device.

A possible solution could be to provide an "annotation object" that could be combined with other grid objects and printed to viewports. Upon printing, this annotation object would insert information at the appropriate point.

Improve the testthat output with a better reporter. This gist contains a start.

Some nice features to have:

• Detailed profiling information for the graph creation phase. This will help us determine how to speed up operations related to creating .tex files such as metric calculations.
• Timing information for the graph compilation phase. This will help us determine if any changes made in the creation phase result in TeX code that compiles faster (Perhaps TeX memory usage as well?).

I have two quick suggestions for zzz.R since I see it is slightly slow to load tikzDevice:

• no need to require(filehash) as long as it is stated in DESCRIPTION
• if the user has specified the options in advance (e.g. in .Rprofile), tikzDevice may just go with them and do not go through the process of checking pdflatex and xelatex

Figure out how to do UTF8 support using pdftex in a sane way. pdftex is the garden variety of TeX that everyone has and uses to power latex and pdflatex.

The changes implemented in the fontsize branch provide better handling of string widths-- especially in ggplot2 graphics. However I just noticed an issue with the placement of exponents arising from ggplot2 scales such as:

plot_x_log10()

I still need to make a test case the definitively isolates this problem.

TikZ can produce output that is friendly for both plain TeX and ConTeXt. Look into supporting these systems.

The Vignette contains many sections that are essentially duplicates of the manual pages for various functions --- specifically sections 3 and 4.1 -- 4.4. It is a pain to ensure both copies of this information are in sync with each other, so perhaps they should be removed.

Another option would be to figure out if it is somehow possible to attach the PDF versions of the manpage as an Appendix to the vignette thus keeping the functionality of the Vignette as a "one stop" reference for the package.

Similar to the onefile option to the pdf() device.

This could be useful for micro-managing how plots are arranged in a tex document yet still generating them in a loop. May be especially useful when using Sweave.

So users have access to package changes from the news function.

I am rather new to R so forgive me if this is obviously stupid. Using the following example with tikzDevice 0.6.2:

library(tikzDevice)

x <- 1:10
y <- sin(x)

tikz("test.tex",standAlone=TRUE)
plot(x,y)
dev.off()

pdf("test2.pdf")
plot(x,y)
dev.off()
q()

I get rather equal distances of the tick labels to the ticks for x and y axes. The tikzdevice output (when run through pdflatex) has different spacings when comparing x and y axis. The space between ticks and labels of the x axis are larger than for the y axis. Is this expected? What can I do?

There are a lot of places where the tikzDevice version number and datestamp are used in source code, documentation, etc. Updating these version numbers should be made automagic by good use of git tag -a and git describe.

This involves fleshing out the TikZ_Cap() function which is currently a stub in version 0.5.0.

Following changes to warnings/errors concerning unicode:

• If XeLaTeX doesn't have a glyph for a given character it will print the following log message:

  Missing character: There is no α in font cmr10!

  getMetricsFromLatex should detect these messages in the log file and:

  • Print a warning message so the user knows they may need to switch fonts. Missing characters get replaced with blank spaces in the final output.
  • Return invalid metrics so that an entry won't get created in the metrics dictionary (currently string width is calculated as 1).

• Change pdftex unicode error to a warning. This error is currently thrown because it is very difficult to determine which packages need to be loaded in order to provide glyphs for a given Unicode character (XeTeX resolves this with better support for fonts). However, many users will know what to place in tikzLatexPackages in order to make things work. Therefore, the error should be changed to a warning that:

  • Lets users know they should switch to xetex or manually edit tikzLatexPackages for best results.
  • Can be disabled by setting an option so users who know what they are doing don't get spammed.

R 2.14.0 is adding some new functions to the graphics API. From Brian Ripley:

Secondly, there is the opportunity to add some new facilities in R-devel,
to be released as R 2.14.0 on October 31. These are the components

devHoldFlush()
haveTransparency
haveTransparentBg
haveCapture
haveRaster
haveLocator

documented in src/include/GraphicsDevice.h. (If you include them, you
should condiitionalize on

if R_GE_version >= 9

endif

.) Screen devices (cairo*, JavaGD ...) will benefit from implementing
dev.hold/dev.flush (see their help page),

I dont believe there is a way to specify the background border color but tikzDevice uses it nontheless when drawing the background rectangle. The result is not visible on a white background but is when using different colors. See the original report:

I am trying to get a plot with the same background color than the background color of the LaTeX page. However, it seems that tikzDevice is introducing by default a command:

\definecolor[named]{fillColor}{rgb}{1.00,1.00,1.00}
\fill[color=fillColor,] (0,0) rectangle (238.49,238.49);

I searched around to see how to remove this line... did not find... is there any way to remove it?

I am using R 2.13 and tikzDevice 0.6.1 (see below for full sesionInfo).

Here would be full reproducible code:

library(ggplot2)
library(tikzDevice)

part1_main70bis<-rgb(0.05,0.4,0.5,maxColorValue=1)
theme_update(
plot.background = theme_rect(fill = part1_main70bis, colour=part1_main70bis)
)
options(tikzLatexPackages=c("\\usepackage{tikz}","\\usepackage{color}\n\\definecolor{part1}{rgb}{0.05,0.4,0.5}\n\\pagecolor{part1}\n"))
tikz(standAlone=TRUE)
qplot(1,1)
dev.off()

It is this white border I would like to remove, do you see it? The guilty line is this one (line 13):
% \fillcolor=fillColor, rectangle (505.89,505.89);

Thanks!
Matthieu

> sessionInfo()
R version 2.13.1 (2011-07-08)
Platform: x86_64-pc-linux-gnu (64-bit)

locale:
[1] LC_CTYPE=fr_FR.UTF-8          LC_NUMERIC=C
[3] LC_TIME=fr_FR.UTF-8           LC_COLLATE=fr_FR.UTF-8
[5] LC_MONETARY=fr_FR.UTF-8       LC_MESSAGES=en_US.utf8
[7] LC_PAPER=fr_FR.UTF-8          LC_NAME=fr_FR.UTF-8
[9] LC_ADDRESS=fr_FR.UTF-8        LC_TELEPHONE=fr_FR.UTF-8
[11] LC_MEASUREMENT=fr_FR.UTF-8    LC_IDENTIFICATION=fr_FR.UTF-8

attached base packages:
[1] grid      stats     graphics  grDevices utils     datasets  methods
[8] base

other attached packages:
[1] ggplot2_0.8.9    proto_0.3-9.2    reshape_0.8.4    plyr_1.6
[5] tikzDevice_0.6.1 filehash_2.2     rkward_0.5.6

loaded via a namespace (and not attached):
[1] tools_2.13.1

Currently figure sizes must be specified in inches. This should be generalized to at least include centimeters.

source('http://addictedtor.free.fr/graphiques/sources/source_122.R')

The function diagwl from the climatol package calls plot.new() which creates a new tikzpicture; then it calls par() which closes the tikzpicture without creating any content but throws in a \end{scope}, causing compilation to fail.

This is the offending chunk:

\begin{tikzpicture}[x=1pt,y=1pt]
\draw[color=white,opacity=0] (0,0) rectangle (505.89,505.89);
\end{scope}
\end{tikzpicture}

A tikzpicture should NOT be created when there is not content to put in. pdf() does not create a blank page here so we should not.

I'm using lattice to produce plots. I decided to give a try to sanitize text strings. However resulting tikz files miss all my text at all :(

Whenever a color to be used is a shade of gray (r=g=b), tikzDevice should define it with the {gray} model rather than the {rgb} model.

The latest version of the tikzDevice, 0.5.1, was checked against R 2.12.0 while that release of R was in development. This was in order to verify that the the implementation of a stub function for polypath() worked correctly.

The SVN version of R 2.12.0 used in these tests was r52686. When R CMD check is run on 0.5.1 using this version everything passes. However, as shown by:

http://cran.r-project.org/web/checks/check_results_tikzDevice.html

R CMD check produces some pretty gnarly looking errors when compiling the vignette using the latest builds of R 2.12.0 or 2.13.0.

Apparently something happened to R since r52686 that could be causing major issues with our package. Stay tuned.

This was requested by a user a while back, It would likely require a some restructuring of the C code. Usage would be something like ggplot2:

p <- tikz(raw=TRUE)
plot(...)
dev.off()

Or

tikz(raw=TRUE,object='p')
plot(...)
dev.off()

then the user could

print(p)

to print to the screen or

print(p,file='foo.tex')

to print to a file.

The second method would probably be more feasible.

This involves fleshing out the TikZ_Raster() function which is currently a stub in version 0.5.0.

Adding a useDynLib statement to the NAMESPACE file is cleaner than calling library.dynam inside of .onLoad in zzz.R. In addition, we can explicitly declare which C-level routines should be visible to R:

• TikZ_StartDevice
• TikZ_Annotate
• TikZ_DeviceInfo

Appears there is some issue preventing the vignette from building. This is blocking binary builds on CRAN although it is being flagged as a NOTE rather than a ERROR. Just ran into it for the first time when prepping the r-forge branch for a release. Gist of log here.

Coincidentally, Murphy's law is goddamn spooky. I ran this operation for three different versions of R on 3 different platforms and the bug doesn't show up until AFTER the CRAN release? WTF!?!

Now that XeTeX is officially supported by the tikzDevice. It should be easy to add support for LuaTeX as it is also Unicode-based and can use many of the advanced font handling packages available to XeTeX.

A key difference between XeTeX and LuaTeX is that XeTeX is DVI-based (routing it's output through xdvipdfmx) and therefore cannot use some packages that require a direct route to PDF. On the other hand, LuaTeX is the official sucessor to PdfTeX and therefore renders directly to PDF.

With the default bg="transparent", we get this at the beginning of every tikzDevice picture:

\fill[color=fillColor,fill opacity=0.00,] (0,0) rectangle (width, height);

This command's only effect is to bulk up the generated PDF. It should not be emitted at all. In general, \fill[...,fill opacity=0,...] should never be generated. A closely related phenomenon is

\draw[fill=fillColor, draw opacity=0.00,] ... ;

which should be optimized to

\fill[color=fillColor] ...;

(And even these are only special cases of the general observation that {fill/draw} opacity=0 and {fill/draw} opacity=1 should never appear in the generated drawing.)

In commit 00b8efb5f3a

> tikz()
Warning: stack imbalance in '.External', 8 then 9
Warning: stack imbalance in '{', 6 then 7

Likely something in Print_Tikz_Header

The Vignette needs to be updated before the release of R 2.13.0 on April 16. Known issues:

• 2.13.0 requires that Vignettes containing non-ASCII characters load the LaTeX inputenc package and declare their encoding. As I recall, loading inputenc causes fonts to be horribly pixelated when scaled on certain platforms, such as Windows. Wierd bug.

  Possible Solutions:

  1. Hit comp.text.tex and tex.stackexchange.com and figure out what causes this inputenc bug and how to avoid it.
  2. Remove all non-ASCII symbols from the vignette. Currently, these are sets of quotes on lines 465, 472 and 474 that can easily be replaced with ``'`.

  I'm leaning towards option 2 as a quick fix, unless the XeTeX additions currently under review add more UTF8 content to the Vignette.

• Updates to the Sweave internals have broken the Mother of All R hacks. Again. Need to make a new driver patch and update patchSweave.R.

The R Graphics API Version will be bumped again in 2.12.0 to support "polygons with holes". See the following post by Paul Murrell for details:

http://r.789695.n4.nabble.com/support-for-polygons-with-holes-td2270301.html#a2270301

Constructs such as

\begin{tikzpicture}[x=1pt,y=1pt]
\definecolor[named]{drawColor}{rgb}{0.00,0.00,0.00}
\definecolor[named]{fillColor}{rgb}{1.00,1.00,1.00}
\begin{scope}
\path[clip] (  0.00,  0.00) rectangle (144.54,144.54);
\definecolor[named]{fillColor}{rgb}{1.00,1.00,1.00}
\fill[color=fillColor] (  0.00,  0.00) rectangle (144.54,144.54);
\end{scope}
\begin{scope}
\path[clip] (  0.00,  0.00) rectangle (144.54,144.54);
\definecolor[named]{drawColor}{rgb}{0.00,0.00,0.00}
\node[color=drawColor,anchor=base,inner sep=0pt, outer sep=0pt, scale= 1.20] at ( 73.39,  9.03) {1};
\end{scope}
\begin{scope}
\path[clip] (  0.00,  0.00) rectangle (144.54,144.54);
\definecolor[named]{drawColor}{rgb}{0.00,0.00,0.00}
\node[rotate= 90.00,color=drawColor,anchor=base,inner sep=0pt, outer sep=0pt, scale=  1.20] at ( 17.30, 76.40) {1};
\end{scope}
\end{tikzpicture}

contain a great deal of repetitive clipping and color specification. It would be better to emit

\begin{tikzpicture}[x=1pt,y=1pt]
\definecolor[named]{drawColor}{rgb}{0.00,0.00,0.00}
\definecolor[named]{fillColor}{rgb}{1.00,1.00,1.00}
\path[clip] (  0.00,  0.00) rectangle (144.54,144.54);
\fill[color=fillColor] (  0.00,  0.00) rectangle (144.54,144.54);
\node[color=drawColor,anchor=base,inner sep=0pt, outer sep=0pt, scale= 1.20]  at ( 73.39,  9.03) {1};
\node[rotate= 90.00,color=drawColor,anchor=base,inner sep=0pt, outer sep=0pt, scale=  1.20] at ( 17.30, 76.40) {1};
\end{tikzpicture}

or, even better, noticing that the colors used are black and white,

\begin{tikzpicture}[x=1pt,y=1pt]
\path[clip] (  0.00,  0.00) rectangle (144.54,144.54);
\fill[color=white] (  0.00,  0.00) rectangle (144.54,144.54);
\node[anchor=base,inner sep=0pt, outer sep=0pt, scale= 1.20]
 at ( 73.39,  9.03) {1};
\node[rotate= 90.00,anchor=base,inner sep=0pt, outer sep=0pt, scale=  1.20]
 at ( 17.30, 76.40) {1};
\end{tikzpicture}

Once Annotations for grid graphics is completed TikZ annotations will be available as Grid grob objects and would be nice to provide GGplot graphics with easy access to TikZ annotation using a custom geom object.

Something like the way geom_text works:

p <- qplot(wt, mpg, data = mtcars) + geom_tikz(1,1, 'node', "wow!")
print(p)

The actual semantics of geom_tikz can be worked out later. The first step will be to ensure GGplot coordinate transformations are taken into account when placing annotations.

The following code demonstrates the bug:

tikz("try.tex", standAlone=TRUE)
 op<-par(bg=11,bty="n", cex=2, mar=c(3,4,1,2)+0.1)
 x <- runif(100)
 plot(x, las=1, yaxt="n",tcl=0, ann=F, type="l", lwd=2, col="blue")
 grid(col="white", lty="solid", nx=NA, ny=NULL, lwd=2)
 lines(x, col="blue", lwd=2)
 axis(1, tcl=0, labels=FALSE, col="black", lwd=1, at=as.Date(c("1970-01-01","2011-01-01")))
 axis(2, las=2, tick=FALSE)
 par(op)
dev.off()

There should be a green background but it is white. In addition, changing the tikz 'bg' parameter actually has no effect, it is never actually used in the code.

The hack in question is used by the vignette to beat some flexibility into Sweave. Recently, the code had to be redone in order to accomodate changes to Sweave in R 2.12.0.

The result has grown even more monstrous as it checks the R SVN revision number in order to determine which version of the hack to apply---eventually the hack will become a maintenance nightmare.

There is hope in that Romain Francois recently submitted a patch to R-devel that will allow Vignettes to load their own custom Sweave drivers---it is not in R-trunk yet but hopefully it will make it.

tikzDevice.c:1425: warning: initialization discards qualifiers from pointer target type

This is due to mismatches of char * with const char *. Need to fix before v0.5 on CRAN.

Plotmath expressions are not handled really at all by tikzDevice; anything that uses %operators% causes the string sanitizer to barf, Greek letters show up as the Latin letter corresponding to the position of the character in the Adobe Symbol font, and those are just the problems I've noticed so far.

Ideal behavior would be for the device to translate plotmath into proper TeX math expressions, but I've no idea how difficult that would be.

Concrete test case 1:

suppressPackageStartupMessages(library(tikzDevice))
tikz("plotmath.tex", standAlone=TRUE, width=1, height=1)
par(mai=c(0,0,0,0))
plot.new()
# the next two lines should produce identical (but for positioning)
# draw commands in the output, but they don't
text(.5, .6, expression(alpha+beta+gamma+delta))
text(.5, .4, "$\\alpha+\\beta+\\gamma+\\delta$")
invisible(dev.off())

Concrete test case 2:

suppressPackageStartupMessages(library(tikzDevice))
tikz("plotmath2.tex", standAlone=TRUE, sanitize=TRUE)
demo(plotmath)
invisible(dev.off())

-->

> draw.plotmath.cell(expression(x %+-% y), i, nr); i <- i + 1
Error in function (string, strip = getOption("tikzSanitizeCharacters"),  : 
  Unable to sanitize string, you may be trying to pass in an unsupported symbol

To be clear, I see this as a feature request rather than a bug, and I do have a workaround (edit all my graphics and replace plotmath with proper TeX math).