Re: [O] plotting tables

[John Hendy]

On Sun, Mar 24, 2013 at 1:44 AM, Eric Abrahamsen
<address@hidden> wrote:
> I'm trying to get my head around plotting data from org tables, for use
> in LaTeX exports. I've been looking at these two pages:
>
> http://orgmode.org/worg/org-tutorials/org-plot.html
> http://orgmode.org/worg/org-contrib/babel/languages/ob-doc-gnuplot.html
>
> As far as I can tell, there are two general approaches. One is an org
> table with some #+PLOT declarations, and when I call `org-plot/gnuplot'
> on it, gnuplot processes the table and shows it to me. Presumably I can
> make it save to a file instead, I haven't investigated that yet.
>
> The other approach seems to be using a named table, and then a gnuplot
> source block that accepts the table data as a variable. In this case
> you're writing an actual gnuplot script, rather than feeding gnuplot
> options into a #+PLOT line.
>
> My questions:
>
> 1. Are these really mutually incompatible approaches, as they appear to
> be?
>

What do you mean by incompatible? I think if you used them both, you'd
just get two plots. It looks like #+plot just allows one to put some
gnuplot commands in the header above a table and get a plot out. Using
the org-babel approach lets you write straight gnuplot code and call a
data table from elsewhere.

I wrote ob-doc-gnuplot, long ago that I didn't really remember why.
- http://www.mail-archive.com/address@hidden/msg28988.html

It looks like I was running into limitations with the #+plot syntax
and switched to using #+begin_src gnuplot because of that.

If you had a #+plot header and #+begin_src gnuplot with the same code,
both calling the table, if you had the correct :exports and :results
options in the block, you'd probably get to graphs.

> 2. What's my best option if I want the following scenario: I start with
> an org file containing an org table, call `org-latex-export-to-pdf' on
> that file, get a coffee, and come back to find a nice pdf containing
> just the plotted graph (no table). Can someone show me just the barest
> example?

Nice PDF of the plot and nothing else whatsoever, or nice PDF
containing other stuff from your org file and just not the header? If
you just want a standalone pdf, you can just use the file option
(assuming gnuplot will write to a pdf) in your code block:

#+begin_src gnuplot :file plot.pdf :exports results :results output

Something like that?

Otherwise, you could just hide the table in a headline with the :noexport: tag:

* Heading 1

Contains stuff you want in a resultant pdf file.

#+begin_src gnuplot :var data=foo

#+end_src gnuplot

** Data table          :noexport:

#+tblname: foo
| data table here |

That would keep the table hidden in a non-exported headline.

> 3. I've been learning the tikz LaTeX package and am very impressed. Has
> anyone used tikz/pgfplots with org?
>

Yes! Though as with Dieter, I've also migrated to R now. Gnuplot
worked fairly well for simple plotting, but at the end of the day,
most plotting (for me, at least) falls into some sort of workflow:
- get some data
- re-arrange, combine, pre-process some data
- get that data accessible to some program (e.g. gnuplot, R)
- plot results
- interpret results
- present plots in context of some project/endeavor

Sure you can just start feeding gnuplot from a file instead of having
big tables in Org-mode tables (which I find gets extremely cumbersome
for more than maybe 20 or so rows and 10 cols), but for most things
you actually need to *do* other things with that data.

If you're just learning... I'd recommend just switching to learning to
plot with R. Ditch other R stuff if it's intimidating at the moment --
just manipulate your data in Excel or LibreOffice, and teach yourself
the equivalent of plotting in gnuplot with R. Instead of =plot data
using 1:3=, it might be =plot(data[, 1], data[, 3])= in R.

The benefit is that as you learn, you can "grow into R," whereas if
you attempt some level of gnuplot mastery, you'll still be stuck
needing a bunch of other tools for all but the more simply plotting
needs.

For matching fonts/styles in your LaTeX output, there's the handy
=tikzDevice= R library: ETA: gasp! It's been removed from CRAN. You
can still get it, though:
- https://www.nesono.com/node/403

Here's the documentation:
- 
https://r-forge.r-project.org/scm/viewvc.php/*checkout*/pkg/inst/doc/tikzDevice.pdf?revision=35&root=tikzdevice

You can add frequently used options in ~/.Rprofile (just create it if
it doesn't exist). Of particular interest is setting the
tikzLatexPackages variable. The following would set your document to
use the =mathpazo= font family instead of the default. You could
replace with whatever you wanted (I use lmodern a lot).

options( tikzLatexPackages = c(
getOption( "tikzLatexPackages" ),
"\\usepackage{mathpazo}"
))


>From there, you'd do something like so:

#+begin_src R

[any general R code]

tikz(file = "file.tex", width = n, height = n, standAlone = T)

[commands that generate the plot in R]

dev.off()

#+end_src

Now you'll have a .tex file of your plot and can just compile it.
Better yet, just add this after =dev.off()= above:

#+begin_src R

tools::texi2dvi("file.tex", pdf=T)

#+end_src

That would compile the resultant file. I tend to get the output in
some other format to make sure things look good and then do the output
to .tex -> pdf as the final step.

As a bonus to this process, if there's ever any re-arrangement or more
complex annotation to be done, you can add it to the .tex file before
compiling. This is fairly manually intensive, but for some things when
you just couldn't specify it based on the data to have it
automatically plotted, you'd end up doing the same amount of work in R
to add text here and there anyway. By looking at the tikz code, you
can generally figure out the min/max coordinates of the plot and add
whatever additional graphics or text you want. You also get fine-tuned
color/shape changing abilities.


Hope that helps!
John



>
> In return, I promise to add a very hand-holdy explanation to worg,
> provided that there isn't already one there that I missed.
>
> Thanks,
> Eric
>
>