emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Eric Abrahamsen <eric@ericabrahamsen.net>
To: emacs-orgmode@gnu.org
Subject: Re: plotting tables
Date: Tue, 26 Mar 2013 11:09:34 +0800	[thread overview]
Message-ID: <87wqsuamc1.fsf@ericabrahamsen.net> (raw)
In-Reply-To: CA+M2ft-uUg+7k69M2Mb0C5K_z+FsvnJyi7ctTuPsLxivuAjEhQ@mail.gmail.com

John Hendy <jw.hendy@gmail.com> writes:

Wow, thank you for this comprehensive response!

> On Sun, Mar 24, 2013 at 1:44 AM, Eric Abrahamsen
> <eric@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

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
  \addplot {table};

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!


> 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

  reply	other threads:[~2013-03-26  3:04 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-24  6:44 plotting tables Eric Abrahamsen
2013-03-24 10:42 ` Dieter Wilhelm
2013-03-24 17:33 ` John Hendy
2013-03-26  3:09   ` Eric Abrahamsen [this message]
2013-03-26 15:19     ` John Hendy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87wqsuamc1.fsf@ericabrahamsen.net \
    --to=eric@ericabrahamsen.net \
    --cc=emacs-orgmode@gnu.org \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).