John Hendy <jw.he...@gmail.com> writes:
Wow, thank you for this comprehensive response!
> On Sun, Mar 24, 2013 at 1:44 AM, Eric Abrahamsen
> <e...@ericabrahamsen.net> wrote:
[...]
>> 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.
Right, "incompatible" was the wrong word, I probably meant "orthogonal".
I just meant you'd either use one or the other, not both.
>> 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?
Sorry, that wasn't clear: there's lots of stuff in the file and I want
all the rest of it, just not the table. A noexport tag is a fine solution to
keeping it out. But I'm still not sure how the resulting plot gets
included: surely I'd need a link to a file in here somewhere?
[...]
>> 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
Over the past couple of days I think I've decided to move away from
gnuplot. What you and Dieter said is right: pgfplots does everything I
need it to, and it integrates perfectly into my existing latex
documents.
I'm reluctant to learn R: frankly my brain is full right now, and I'm
also not sure I need it. My data is actually very simple and doesn't
require any massaging that the org tables themselves can't handle. I do
have a lot of small tables, though, will need to produce these documents
fairly frequently, and need them to look good.
So in your setup below, you're using R to actually create the plots, but
tikz to style them? Or is R feeding data to tikz/pgfplots, and the
actually plotting is going on there? I found this a little confusing...
What I believe I'm looking for is something like this:
#+tblname: tabul
| Dec | Nov | Oct | Sept |
+------+------+------+------|
| 1575 | 3430 | 332 | 2201 |
| 3118 | 3002 | 2334 | 1053 |
#+begin_src latex :var table=tabul
\begin{tikzpicture}
\begin{axis}[blah]
\addplot {table};
\end{axis}
\end{tikzpicture}
#+end_src
Except that I'll need an intermediate step, so that table headings go
into separate vars and are put in the axis declaration, and the actual
table data comes out in a format that pgfplots can understand (right now
it's a sexp).
Maybe that's where R comes in?
Thanks again for all this information!
E
> 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
>>
>>
