Have a look at the xtable package, which prints LaTeX tables neatly. I have used this a lot for Sweave auto-generated reports.
The following is a toy example of printing some tables for LaTeX in a Sweave document
<<echo=FALSE,print=FALSE,results=tex>>
## generate an example set of tables
library(xtable)
data(tli)
my.tables <- list()
for(iTable in 1:20){
my.tables[[iTable]] <- tli[1:20 + iTable,]
}
## print these out, with page breaks in between
for(iTable in 1:20){
print(xtable(my.tables[[iTable]]))
cat('\\clearpage\n')
}
@
Graphics with lots of points are always a challenge for TeX-based processors.
However, I am convinced that both memory and time limitations can be tackled to "reasonable" degree (i.e. to reduced pain).
There are two solutions which should both be considered:
to increase TeX's memory (or to circumvent the limitations of pdflatex).
to reduce the number of times the graphic is being processed by TeX (compile once, use often).
While the comments to your question already indicate some solutions concerning (2.), you may need more input for (1.). In fact, I believe that (1.) is the more pressing issue which cannot easily be solved by (2.).
Concerning (1.), I know that one solution works pretty well: to increase the limits. The pgfplots manual contains details instructions for both windows and linux how to enlarge the memory limits. I consider that to be a mandatory step for you - and invite you to follow the link above and read chapter "6 Memory and Speed Considerations" in the pgfplots manual. The chapter contains readily deployable configuration examples. It might be that switching to lualatex instead of the conventional tools (pdflatex or latex/dvips) might also solve the memory problem (I do not know).
Concerning (2.), you can use the standalone package (this site contains a lot of examples). This should work with any of your packages. However, if you use matlab2tikz, I find the TikZ library external very useful here - I tailored it to convert each figure to a separate pdf without changing the original document. Note that matlab2tikz uses pgfplots, so the link mentioned above might be very useful (it also contains a brief description of this automatic image externalization).
I believe that the steps above should help.
But there are always cases where one might also want to know about alternatives.
Here are some of them. I did not post them directly because I have the impression that you may already have an existing workflow and they may not fit - but perhaps you are interested in my experiences anyway:
a) you could try to implement (selected) figures directly in TeX. I did so by means of pgfplots which is quite powerful. I like the fact that I could define document-wide consistent styles and that the single documents are, well, often easier to read than autogenerated code. In fact, once I started using pgfplots instead of matlab, I found that both simpler to maintain (.tex files instead of .m files) and prettier. I dropped all of my matlab scripts eventually and used only pgfplots in the end.
b) if your vector graphics are too large, you may want to consider using bitmap graphics and use TeX to overlay axis descriptions over the bitmap. pgfplots comes with its \addplot graphics and \addplot3 graphics commands to streamline the process. You can also post feature requests to Nico Schloemer (author of matlab2tikz) - perhaps he is willing to add automatic bitmap conversion with overlay axes. Details for such an approach can be found in the aforementioned pgfplots manual (including application examples). Bitmap graphics have the advantage that they render much faster in all viewers - and for surface plots, it does not matter anyway.
Best Answer
There are three ways of doing this:
Do the weaving at the application (Matlab, Mathematica, R) end. That is, the application should be aware of the TeX format and ignore everything other than
\begin{code}...\end{code}snippets. This is how Sweave and literate haskell work.Do the weaving at the TeX end, that is, let TeX call the external application (with appropriate switches) and then display the result. This the approach that the
Randgnuplotmodules in ConTeXt follow.Use a general purpose literate programming tool, like noweb (or those targeted to a specific language like Ocamweb).
For the second approach, I have written a ConTeXt module, filter, that allows you to pass the content of a program to an external program and read back the results. For example, you can replicate the functionality of sweave using:
Then, using
will execute the resultant code using
Rand show the output generated byR. Usingwill execute the code using
Rbut not show the output. The same approach will work for Matlab or Mathematica by replacing thefiltercommandby the appropriate call to Matlab/Mathematica. This approach can be used for other purposes as well