Re: [O] Proposal/request for input: slidify export for html slides
On Sat, Feb 8, 2014 at 11:18 AM, Charles Berry ccbe...@ucsd.edu wrote:
I still think it makes sense to allow :eval no. This seems more
Org-ish since the ideology is to have one set of Org syntax where
possible, which translates to any number of languages. [...]
In principal, it makes sense to map babel header args to knitr chunk
options. At least when the headers arg and chunk option do about the
same thing.
But there is some effort and overhead involved, so only the most
useful (IMO) have been mapped. Right now, `:noweb yes' will expand the
reference(s) in place before export, and `:exports none' will not export
the block. Maybe one day ...
Understood, and no worries. I'm making progress. When you say expand
references, I'm not sure I follow what that means. References =
references to variables? So something like :var something=something?
More a matter of what my workflow is (so the issue doesn't arise). I use
the cache=TRUE chunk option on the knitr side to save the results of long
running computations. When I start work, I execute a src block that loads
knitr and knits the *.Rnw (or *.Rmd, etc), which has the side effect of
loading the cached objects. Then I edit the *.org document. If I am
working on R code, I run the code interactively either from the src edit
buffer or I C-c C-c the src block. Its handy to leave the results in the
*.org buffer for reference - they get stripped on export. Maybe I edit
a figure caption (knitr option fig.cap=R character object), equations,
or text. When I am ready to see the formatted doc, I export via ravel,
knit, and view. The cached objects get rebuilt as needed.
Ah. I think I follow this. If you knit the exported .org - Rmd file
in the same R session that Org is using, if you change the .org and
re-export to .Rmd, knitr is smart enough not to re-run the code? Is
that what you mean? That also must imply that export to .Rmd doesn't
execute any of the Org babel code, right (otherwise there would be no
benefit to your workflow since you'd be waiting for Org anyway)?
If that's the case, I think I could roll with that -- I'd just have
:eval yes if exporting to .Rmd - knitr, and do a replace-string to
:eval no if I was going to export to Beamer.
My workflow might be odd in that I tend to futz with plot parameters
once, get the desired image, and then set :eval no for the rest of my
document work so I don't have to wait for plots on iterative exports.
I try to put all my setup code (load packages, data
reading/manipulation, etc.) in it's own block so that I can easily run
that whenever I first open the document. From there I only need to
re-run a plot block if necessary and I'll just temporarily change
:eval no - yes and then back again after execution.
Not odd at all if it saves you time.
But if it takes long to rebuild the objects in that first src block, you
might want to try the cache=TRUE route.
I'm a bit hung up on including non-code-generated images. I'm working
through one of my presentations to convert to slidify (and may write
up a Worg tutorial or just one on my blog to add to collective
knowledge) but am not sure of the right universal Org syntax that
will work with multiple backends. I'm most used to something like
this:
#+begin_center
#+attr_backend :height {6cm, 400px, etc.}
[[./path/to/image.png]]
#+end_center
That's not seeming to work with ox-ravel thus far. I'd love not to
have to change the Org image syntax to straight markdown just for my
occasional use of slidify.
Thanks again -- you've been immensely helpful in getting me started!
John
Chuck
p.s. the weird fontification you noted one posting up in this thread seems
like something to raise with the slidify/knitr devs after checking the
*.Rmd to be sure there is no org/ravel induced problem.
Will do, but I'm really thinking it's got to be crud that exported
from my various latex lines/settings. If things persist after making
sure none of that made it through to .Rmd, I'll submit an example file
to either knitr or slidify github issues.
Re: [O] Proposal/request for input: slidify export for html slides
John Hendy jw.hendy at gmail.com writes:
On Sat, Feb 8, 2014 at 11:18 AM, Charles Berry ccberry at ucsd.edu wrote:
[snip]
But there is some effort and overhead involved, so only the most
useful (IMO) have been mapped. Right now, `:noweb yes' will expand the
reference(s) in place before export, and `:exports none' will not export
the block. Maybe one day ...
Understood, and no worries. I'm making progress. When you say expand
references, I'm not sure I follow what that means. References =
references to variables? So something like :var something=something?
'References' refers to noweb references. See
http://orgmode.org/org.html#noweb
More a matter of what my workflow is (so the issue doesn't arise). I use
the cache=TRUE chunk option on the knitr side to save the results of
long
running computations. When I start work, I execute a src block that
loads
knitr and knits the *.Rnw (or *.Rmd, etc), which has the side effect of
loading the cached objects. Then I edit the *.org document. If I am
working on R code, I run the code interactively either from the src edit
buffer or I C-c C-c the src block. Its handy to leave the results in the
*.org buffer for reference - they get stripped on export. Maybe I edit
a figure caption (knitr option fig.cap=R character object), equations,
or text. When I am ready to see the formatted doc, I export via ravel,
knit, and view. The cached objects get rebuilt as needed.
Ah. I think I follow this. If you knit the exported .org - Rmd file
in the same R session that Org is using, if you change the .org and
re-export to .Rmd, knitr is smart enough not to re-run the code? Is
that what you mean?
Almost. ox-ravel does not call knitr. The ravel backends advice
`org-babel-exp-do-export' when a ravel backend runs so R code src blocks
are not run, but are turned into chunks (for knitr, Sweave, or ...) and
exported as such.
When you want to actually process the resulting document, you have to call
on knitr or some other R report generator to do the work.
That also must imply that export to .Rmd doesn't
execute any of the Org babel code, right (otherwise there would be no
benefit to your workflow since you'd be waiting for Org anyway)?
Correct for R src blocks. But emacs-lisp and other languages are treated as
under the parent backends.
If that's the case, I think I could roll with that -- I'd just have
:eval yes if exporting to .Rmd - knitr, and do a replace-string to
:eval no if I was going to export to Beamer.
In R scr blocks, :eval is ignored by ravel and so need not change when
ravel is run.
[snip]
I'm a bit hung up on including non-code-generated images. I'm working
through one of my presentations to convert to slidify (and may write
up a Worg tutorial or just one on my blog to add to collective
knowledge) but am not sure of the right universal Org syntax that
will work with multiple backends. I'm most used to something like
this:
#+begin_center
#+attr_backend :height {6cm, 400px, etc.}
[[./path/to/image.png]]
#+end_center
That's not seeming to work with ox-ravel thus far. I'd love not to
have to change the Org image syntax to straight markdown just for my
occasional use of slidify.
It's not related to ox-ravel, which uses the same transcoders as the parent
backends for everything except inline src and src blocks.
I'm not sure how to get what you seem to want.
Maybe use a custom link
http://orgmode.org/org.html#Adding-hyperlink-types
or ask about html/md links in a fresh thread?
HTH,
Chuck
Re: [O] Proposal/request for input: slidify export for html slides
On Sun, Feb 9, 2014 at 10:16 PM, Charles Berry ccbe...@ucsd.edu wrote:
John Hendy jw.hendy at gmail.com writes:
On Sat, Feb 8, 2014 at 11:18 AM, Charles Berry ccberry at ucsd.edu wrote:
[snip]
Ah. I think I follow this. If you knit the exported .org - Rmd file
in the same R session that Org is using, if you change the .org and
re-export to .Rmd, knitr is smart enough not to re-run the code? Is
that what you mean?
Almost. ox-ravel does not call knitr. The ravel backends advice
`org-babel-exp-do-export' when a ravel backend runs so R code src blocks
are not run, but are turned into chunks (for knitr, Sweave, or ...) and
exported as such.
When you want to actually process the resulting document, you have to call
on knitr or some other R report generator to do the work.
I think I stated it ambiguously before. I think we're on the same
page. Org - Rmd. Then process Rmd in an Emacs R session. If you
re-export from Org - Rmd, only new code block changes are re-run,
correct?
That also must imply that export to .Rmd doesn't
execute any of the Org babel code, right (otherwise there would be no
benefit to your workflow since you'd be waiting for Org anyway)?
Correct for R src blocks. But emacs-lisp and other languages are treated as
under the parent backends.
If that's the case, I think I could roll with that -- I'd just have
:eval yes if exporting to .Rmd - knitr, and do a replace-string to
:eval no if I was going to export to Beamer.
In R scr blocks, :eval is ignored by ravel and so need not change when
ravel is run.
Ah, that makes more sense. I guess I had all mine set to :eval no and
never experienced that ox-ravel doesn't actually run them. Thanks for
that.
[snip]
I'm a bit hung up on including non-code-generated images. I'm working
through one of my presentations to convert to slidify (and may write
up a Worg tutorial or just one on my blog to add to collective
knowledge) but am not sure of the right universal Org syntax that
will work with multiple backends. I'm most used to something like
this:
#+begin_center
#+attr_backend :height {6cm, 400px, etc.}
[[./path/to/image.png]]
#+end_center
That's not seeming to work with ox-ravel thus far. I'd love not to
have to change the Org image syntax to straight markdown just for my
occasional use of slidify.
It's not related to ox-ravel, which uses the same transcoders as the parent
backends for everything except inline src and src blocks.
I'm not sure how to get what you seem to want.
What I mean is how do I just add an image via existing Org syntax and
get it sized correctly in the Org - Rmd - html process? None of the
attributes seem to be carried through to markdown with ox-md or
ox-ravel. So my question might be more clear if I said, Say you have
an image that's 1600x900px and you want it in your slidify deck at
400px tall. How would you do that?
ox-ravel works fine by just specifying knitr fig.height/width if
you're going to generate your plots during the process of knitting.
You create the plot at exactly the size you want. But how might you
resize an existing plot depending on the format? If you want an html
equivalent to the latex article class, you might want a different plot
size than if you want to export to slidify. Would one have to go
through and replace all the fig.height/width arguments and re-run all
the plot code just to get proper image sizing? Once there are
perfectly good images laying around... it doesn't seem like one should
have to re-generate them just because a different size is desired.
Maybe use a custom link
http://orgmode.org/org.html#Adding-hyperlink-types
or ask about html/md links in a fresh thread?
I posted another ML post along these lines earlier today. Since
markdown is just a middle destination onto html, I'm interested in
getting Org's built-in image attributes passed along for the whole
trip. I don't see a way to even center an image at present. The direct
img tag could be put in Org... but that breaks the spirit of
keeping Org's syntax flexible enough to let me export to another
backend if I want. Thus, the ideal goal would be something like:
#+begin_center
#+attr_latex: :height 6cm
#+attr_html: :height 400px
#+attr_ravel: :height 400px
[[./img.png]]
#+end_center
Thus I get a centered image at some appropriate size for each backend.
Otherwise I'll be having to do #+begin/end_latex and #+begin/end_html
for every image in my document.
Does that make more sense?
John
HTH,
Chuck
Re: [O] Proposal/request for input: slidify export for html slides
Hello, John Hendy jw.he...@gmail.com writes: One other question while we're at it... I noticed that #+begin/end_center produces this in the output .md file: div class=center  /div This nil looks like a bug. What should be expected instead? Regards, -- Nicolas Goaziou
Re: [O] Proposal/request for input: slidify export for html slides
On Feb 8, 2014 3:32 AM, Nicolas Goaziou n.goaz...@gmail.com wrote: Hello, John Hendy jw.he...@gmail.com writes: One other question while we're at it... I noticed that #+begin/end_center produces this in the output .md file: div class=center  /div This nil looks like a bug. What should be expected instead? Typical markup would be a description string on some sort. Maybe just 'img' for general images and the content of #+name for Babel results? John Regards, -- Nicolas Goaziou
Re: [O] Proposal/request for input: slidify export for html slides
John Hendy jw.he...@gmail.com writes: Typical markup would be a description string on some sort. Maybe just 'img' for general images and the content of #+name for Babel results? OK. I fixed it in maint. img will be always used as alt text. I also fixed caption location. Thank you. Regards, -- Nicolas Goaziou
Re: [O] Proposal/request for input: slidify export for html slides
John Hendy jw.hendy at gmail.com writes:
On Fri, Feb 7, 2014 at 11:38 PM, John Hendy jw.hendy at gmail.com wrote:
On Fri, Feb 7, 2014 at 7:04 PM, Charles Berry ccberry at ucsd.edu wrote:
[snip]
I'll look into those. I just cloned your repo and loaded ox-ravel.
Quite nice! It worked /pretty/ well out of the box. One issue is that
it doesn't seem to obey :eval no for babel blocks. I exported to .Rmd
successfully, but the presentation has a bunch of errors in the code
blocks from trying to actually execute the code. The .Rmd doesn't have
any instances of ```{r eval=F}; could this feature be added?
Just kidding. Discovered #+attr_ravel and the proper knitr argument
for code chunks, which worked as expected with:
#+attr_ravel: eval=F
#+begin_src R ...
I still think it makes sense to allow :eval no. This seems more
Org-ish since the ideology is to have one set of Org syntax where
possible, which translates to any number of languages. [...]
In principal, it makes sense to map babel header args to knitr chunk
options. At least when the headers arg and chunk option do about the
same thing.
But there is some effort and overhead involved, so only the most
useful (IMO) have been mapped. Right now, `:noweb yes' will expand the
reference(s) in place before export, and `:exports none' will not export
the block. Maybe one day ...
I get that we
have #+attr_latex for latex-only things, #+attr_html for html-only
things, and so on, but I wouldn't consider :eval to fall into this
category. Or perhaps I don't understand... would the idea be that I
don't want to run it in *Org*, but I'd not want all my chunks disabled
in the .Rmd?
More a matter of what my workflow is (so the issue doesn't arise). I use
the cache=TRUE chunk option on the knitr side to save the results of long
running computations. When I start work, I execute a src block that loads
knitr and knits the *.Rnw (or *.Rmd, etc), which has the side effect of
loading the cached objects. Then I edit the *.org document. If I am
working on R code, I run the code interactively either from the src edit
buffer or I C-c C-c the src block. Its handy to leave the results in the
*.org buffer for reference - they get stripped on export. Maybe I edit
a figure caption (knitr option fig.cap=R character object), equations,
or text. When I am ready to see the formatted doc, I export via ravel,
knit, and view. The cached objects get rebuilt as needed.
My workflow might be odd in that I tend to futz with plot parameters
once, get the desired image, and then set :eval no for the rest of my
document work so I don't have to wait for plots on iterative exports.
I try to put all my setup code (load packages, data
reading/manipulation, etc.) in it's own block so that I can easily run
that whenever I first open the document. From there I only need to
re-run a plot block if necessary and I'll just temporarily change
:eval no - yes and then back again after execution.
Not odd at all if it saves you time.
But if it takes long to rebuild the objects in that first src block, you
might want to try the cache=TRUE route.
Chuck
p.s. the weird fontification you noted one posting up in this thread seems
like something to raise with the slidify/knitr devs after checking the
*.Rmd to be sure there is no org/ravel induced problem.
Re: [O] Proposal/request for input: slidify export for html slides
John Hendy jw.hendy at gmail.com writes: An interesting update on this. Aside from some image and code block stuff, the following works surprisingly well! - Export Org - markdown (md) - Start an R session and `setwd(/path/to/file.md)` - Run `library(slidify)` and `author(deck) - Copy the deck/assets folder into the parent directory - Copy the header code from the resultant deck/index.Rmd file into exported .md file - Add three hyphens before each heading (headings are # Slide title) - Save the file as file.Rmd (vs. file.md) - From the R session, do `setwd(../)` (running `author(deck)` changes the working directory to deck/ - Run `slidify(file.Rmd)` [much deleted] John, You can put the header code into an MD export block (and ignore index.Rmd). You can add '#+MD: ---' keyword lines to mark new slides. Then you export to my.Rmd directly (using ravel) and run slidify(my.Rmd). Graphics 'just work', but you have to mind the spacing to be sure the slides render nicely. The file slidify-example.org at https://github.com/chasberry/orgmode-accessories/ produces a minimal slidify slideshow with code, computed results, and graphics. And it has some notes on org -- slidify using the md-knitr backend from ox-ravel. Ideally, a `md-slidify' backend would get written to automagically produce the yaml header, separate slides based on headline levels, et cetera. But that is a low priority right now. HTH, Chuck
Re: [O] Proposal/request for input: slidify export for html slides
John Hendy jw.hendy at gmail.com writes:
On Fri, Feb 7, 2014 at 3:50 PM, Charles Berry ccberry at ucsd.edu wrote:
John Hendy jw.hendy at gmail.com writes:
An interesting update on this. Aside from some image and code block
[snip - how John turn org to Rmd to md]
John,
You can put the header code into an MD export block (and ignore
index.Rmd).
You can add '#+MD: ---' keyword lines to mark new slides.
Awesome! Hadn't thought of that, and sounds great.
Then you export to my.Rmd directly (using ravel) and run
slidify(my.Rmd).
Graphics 'just work', but you have to mind the spacing to be sure the
slides
render nicely.
Hmmm. Could you elaborate on this? I haven't experienced this with R +
ggplot. The presentation I'm working on for tomorrow is on geo-spatial
data with R and I generate a lot of maps. I find that something like
this doesn't produce properly scaled images:
#+header: :file .map.pdf
#+begin_src R :results output graphics :exports results
# install.packages(maps)
library(maps)
world - map_data(world)
p - ggplot(world, aes(x = long, y = lat, group = group))
p - p + geom_polygon(colour = white)
p
#+end_src
I often get something squarish, which makes the map look really
compressed (see attached). Thus, I seem to need both this (name,
header)
This is a problem that results from rendering in a square rather than
something proportional to what Mercator used: 202cm x 124cm, I think.
slidify wants to have png files for images, so I think you are stuck
having to set up the size of the device as well as the displayed size
to get nice looking results.
#+name: world-adj
#+header: :file map-adj.pdf :width 9 :height 6
#+begin_src R :results output graphics :exports results
# code from above
#+end_src
and this (right height for latex)
#+begin_center
#+attr_latex: :height 6cm
#+RESULTS: world-map
[[file: world-adj.pdf]]
#+end_center
I guess in this example, the heights are the same, however sometimes
this isn't the case as to use the right height for the slides can goof
with how proportionally big the axis, label, and legend text is and it
requires, in my opinion, wy more work to use the theme() arguments
in ggplot2 to tailor them correctly vs. just playing with
:width/:height options and then scaling the final image in the
#+RESULTS section.
I would love to avoid the above if you have more clarification on just
work :)
I wasn't thinking about the case you just demonstrated. I have to use
a line that gives out.width, out.height, fig.width, and fig.height, which
slidify ('knitr' under the hood) uses to render the png and the page as you
did to make something that looks like the Mercator map and still have
the text look OK. See http://yihui.name/knitr/options if the options
listed are not familiar. (knitr chunk options can be put in #+ATTR_RAVEL:
lines for ravel exports to use them.)
[more deleted]
One other question while we're at it... I noticed that
#+begin/end_center produces this in the output .md file:
div class=center
/div
This doesn't export with slidify. [snip more details]
Right. IMO, using the knitr tools for dealing with such issues beats
wrestling with the babel and md exporter. i.e. fig.align=center handles
this. A good part of my motivation for ox-ravel is that I can deal with
fine tuning output from knitr more easily than I can w/ babel exports.
HTH,
Chuck
Re: [O] Proposal/request for input: slidify export for html slides
On Fri, Feb 7, 2014 at 11:38 PM, John Hendy jw.he...@gmail.com wrote:
On Fri, Feb 7, 2014 at 7:04 PM, Charles Berry ccbe...@ucsd.edu wrote:
[snip]
I'll look into those. I just cloned your repo and loaded ox-ravel.
Quite nice! It worked /pretty/ well out of the box. One issue is that
it doesn't seem to obey :eval no for babel blocks. I exported to .Rmd
successfully, but the presentation has a bunch of errors in the code
blocks from trying to actually execute the code. The .Rmd doesn't have
any instances of ```{r eval=F}; could this feature be added?
Just kidding. Discovered #+attr_ravel and the proper knitr argument
for code chunks, which worked as expected with:
#+attr_ravel: eval=F
#+begin_src R ...
I still think it makes sense to allow :eval no. This seems more
Org-ish since the ideology is to have one set of Org syntax where
possible, which translates to any number of languages. I get that we
have #+attr_latex for latex-only things, #+attr_html for html-only
things, and so on, but I wouldn't consider :eval to fall into this
category. Or perhaps I don't understand... would the idea be that I
don't want to run it in *Org*, but I'd not want all my chunks disabled
in the .Rmd?
My workflow might be odd in that I tend to futz with plot parameters
once, get the desired image, and then set :eval no for the rest of my
document work so I don't have to wait for plots on iterative exports.
I try to put all my setup code (load packages, data
reading/manipulation, etc.) in it's own block so that I can easily run
that whenever I first open the document. From there I only need to
re-run a plot block if necessary and I'll just temporarily change
:eval no - yes and then back again after execution.
Thanks again,
John
Re: [O] Proposal/request for input: slidify export for html slides
An interesting update on this. Aside from some image and code block stuff, the following works surprisingly well! - Export Org - markdown (md) - Start an R session and `setwd(/path/to/file.md)` - Run `library(slidify)` and `author(deck) - Copy the deck/assets folder into the parent directory - Copy the header code from the resultant deck/index.Rmd file into exported .md file - Add three hyphens before each heading (headings are # Slide title) - Save the file as file.Rmd (vs. file.md) - From the R session, do `setwd(../)` (running `author(deck)` changes the working directory to deck/ - Run `slidify(file.Rmd)` I was coming from Beamer, so all of my generated plots are .pdfs. I plan to create a new directory and use imagemagic to convert them all to png or jpg, and then modify my original .org file tailored for Beamer to use the images vs. pdfs, as well as adding #+attr_html headings instead of the existent #+attr_latex ones in my current file. I'll post a test file and the process if anyone is interested in replicating! It seems that src blocks aren't *always* detected properly in the .md file, so I need to figure out what's happening there. I think I should be able to do a pretty easy replace-regexp to replace [^#] (beginning of line followed by #, indicating a header) with [--- [RET] [RET] #] to automatically populate the slide divisions. If any rough spots could be identified and tweaked, the current .md exporter might work brilliantly to create a .Rmd file compatible with slidify if it's of interest to folks. The boilerplate slidify text at the beginning is simple enough to populate, and some variables could set the framework, (io2012, deckjs, etc.), title, author, etc. Best regards, John On Wed, Jan 29, 2014 at 10:26 PM, John Hendy jw.he...@gmail.com wrote: On Jan 29, 2014 7:46 PM, Rick Frankel r...@rickster.com wrote: On Thu, Jan 30, 2014 at 12:57:46AM +, Ahmadou Dicko wrote: I love slidify too and I think that having similar functionnality in org could be great. I think that you have everything to do that using the html backend, you just need to interface the right Javascript/HTML5 library. In slidify you can use io2012, deck.js, shower and landslide and I know that you can use deck.js through ox-deck and it will not be difficult to create and interface for other library too. For example if you need a nice non Beamer library you can also check ox-reveal which interface reveal.js. Just to follow-up and expand. It looks like slidy is an interface for Rstudio to a number of html slide (javascript) libraries, and uses markdown as it markup language, while providing the ability to execute R code interspersed with the markup (literate programming/reproducable results) Org is it's own markup language and allow interspersing executable code (and its output) in a literate, reproducable way (babel). Including, but not limited to, R. In addion org has export interfaces to multiple output types. For slideshow there are (at least): - ox-s5 - ox-deck - ox-reveal - beamer As well as pdf, html and others. So it doesn't seem to make sense to use org as a frontend to Rstudio, but i may be wrong... Agree on most points, and will be checking out the HTML org options as I mentioned. I did want to correct that slidify is not tied to rstudio, even though it integrates nicely with it. I was playing with it when straight from an R session within Emacs when I wrote the post. It also has some nice web publishing features to send the presentation right to git, dropbox, or rpubs from R, (though I didn't try that outside of rstudio, so there could be caveats). John rick
Re: [O] Proposal/request for input: slidify export for html slides
Hi John, John Hendy jw.he...@gmail.com writes: An interesting update on this. Aside from some image and code block stuff, the following works surprisingly well! - Export Org - markdown (md) - Start an R session and `setwd(/path/to/file.md)` - Run `library(slidify)` and `author(deck) - Copy the deck/assets folder into the parent directory - Copy the header code from the resultant deck/index.Rmd file into exported .md file - Add three hyphens before each heading (headings are # Slide title) - Save the file as file.Rmd (vs. file.md) - From the R session, do `setwd(../)` (running `author(deck)` changes the working directory to deck/ - Run `slidify(file.Rmd)` I was coming from Beamer, so all of my generated plots are .pdfs. I plan to create a new directory and use imagemagic to convert them all to png or jpg, and then modify my original .org file tailored for Beamer to use the images vs. pdfs, as well as adding #+attr_html headings instead of the existent #+attr_latex ones in my current file. Are your pdf plots generated (by R) through babel? In that case (and given that you do not rely on absolute positioning) you can make Org /do the right thing/ for you without the need to call imagemagick manually in the end. Making images export correctly across multiple backends is a lot of work (#+attr_latex and #+attr_html should live happily together), so I'll stick to a simple example ;-) --8---cut here---start-8--- * R plot for multiple backends You might even consider tikz for the LaTeX route instead of pdf. #+name: demoplot #+header: :exports results #+header: :results graphics #+header: :file (by-backend (latex demoplot.pdf) (html demoplot.svg) (t demoplot.png)) #+begin_src R ## taken from ?plot plot(table(rpois(100, 5)), type = h, col = red, lwd = 10, main = rpois(100, lambda = 5)) #+end_src #+results: demoplot [[file:demoplot.png]] --8---cut here---end---8--- This relies on the by-backend macro from Eric Schulte: --8---cut here---start-8--- #+begin_src emacs-lisp (defmacro by-backend (rest body) `(case (if (boundp 'backend) (org-export-backend-name backend) nil) ,@body)) #+end_src --8---cut here---end---8--- I'll post a test file and the process if anyone is interested in replicating! Please do so. I guess that somehow such a process should be automatable in the end. [ ... ] Regards, Andreas
Re: [O] Proposal/request for input: slidify export for html slides
I love slidify too and I think that having similar functionnality in org
could be great.
I think that you have everything to do that using the html backend, you
just need to interface the right Javascript/HTML5 library.
In slidify you can use io2012, deck.js, shower and landslide and I know
that you can use deck.js through ox-deck and it will not be difficult to
create and interface for other library too.
For example if you need a nice non Beamer library you can also check
ox-reveal https://github.com/yjwen/org-reveal/ which interface reveal.js.
Here is a minimal example with R code. (Make sure to have ox-reveal.el in
your path and export using C-c C-e R R)
On Thu, Jan 30, 2014 at 12:05 AM, John Hendy jw.he...@gmail.com wrote:
Greetings,
I use R quite a bit, and ran into a new exporter sometime last year called
Slidify:
- http://slidify.org/start.html
Would anyone be able to suggest a good starting place for creating a
possible backend exporter for this? RStudio allows this pretty easily, but
I really like my prose/code in Orgmode format and working within Emacs.
Plus, it allows the obvious benefit of exporting to Beamer or Slidify at
will (perhaps with some tweaks).
I planned to look at the existing non-Beamer libraries for reference, but
thought it wouldn't hurt to inquire about potential pitfalls based in how
Slidify works:
- initializes a git repo with some css/other folders
- creates an index.Rmd file (markdown, which one edits to create
presentation)
- spits out an index.html file when you run `slidify(index.Rmd)`
I think the folders in the presentation directory could be initialized and
then Org syntax could be converted to R markdown, followed by running the
slidify command to compile, but am not sure.
I'm coming from ~zero elisp experience but think this would be a neat
hobby project if I could pull it off.
Thanks for any input,
John
--
Ahmadou H. DICKO
statistician economist (Ingénieur Statisticien Économiste)
PhD candidate in Climate change economics
Faculty of economics and managment - Cheikh Anta Diop University
West African Science Service Center on Climate Change and Adaptated Land
Use (WASCAL)
Center for Development Research (ZEF) - University of Bonn
email : ahmadou.di...@ucad.edu.sn
twitter : @dickoah
github : github/dickoa https://github.com/dickoa
tel : +221 33 827 55 16
portable: +221 77 123 81 69
Title: (Ox-reveal and R)
Ox-reveal and R
@dickoah
Code
Embedding rCharts
library(rCharts)
hair_eye_male = subset(as.data.frame(HairEyeColor), Sex == "Male")
n1 - nPlot(Freq ~ Hair, group = 'Eye',
data = "" type = 'multiBarChart'
)
n1$set(width = 1200, height = 600)
n1$show('inline', include_assets = TRUE, cdn = TRUE)
Code
You can check the raw Org-file here
Created by Ahmadou H. Dicko.
rChart.org
Description: Lotus Organizer
Re: [O] Proposal/request for input: slidify export for html slides
On Thu, Jan 30, 2014 at 12:57:46AM +, Ahmadou Dicko wrote: I love slidify too and I think that having similar functionnality in org could be great. I think that you have everything to do that using the html backend, you just need to interface the right Javascript/HTML5 library. In slidify you can use io2012, deck.js, shower and landslide and I know that you can use deck.js through ox-deck and it will not be difficult to create and interface for other library too. For example if you need a nice non Beamer library you can also check ox-reveal which interface reveal.js. Just to follow-up and expand. It looks like slidy is an interface for Rstudio to a number of html slide (javascript) libraries, and uses markdown as it markup language, while providing the ability to execute R code interspersed with the markup (literate programming/reproducable results) Org is it's own markup language and allow interspersing executable code (and its output) in a literate, reproducable way (babel). Including, but not limited to, R. In addion org has export interfaces to multiple output types. For slideshow there are (at least): - ox-s5 - ox-deck - ox-reveal - beamer As well as pdf, html and others. So it doesn't seem to make sense to use org as a frontend to Rstudio, but i may be wrong... rick
Re: [O] Proposal/request for input: slidify export for html slides
On Jan 29, 2014 7:46 PM, Rick Frankel r...@rickster.com wrote: On Thu, Jan 30, 2014 at 12:57:46AM +, Ahmadou Dicko wrote: I love slidify too and I think that having similar functionnality in org could be great. I think that you have everything to do that using the html backend, you just need to interface the right Javascript/HTML5 library. In slidify you can use io2012, deck.js, shower and landslide and I know that you can use deck.js through ox-deck and it will not be difficult to create and interface for other library too. For example if you need a nice non Beamer library you can also check ox-reveal which interface reveal.js. Just to follow-up and expand. It looks like slidy is an interface for Rstudio to a number of html slide (javascript) libraries, and uses markdown as it markup language, while providing the ability to execute R code interspersed with the markup (literate programming/reproducable results) Org is it's own markup language and allow interspersing executable code (and its output) in a literate, reproducable way (babel). Including, but not limited to, R. In addion org has export interfaces to multiple output types. For slideshow there are (at least): - ox-s5 - ox-deck - ox-reveal - beamer As well as pdf, html and others. So it doesn't seem to make sense to use org as a frontend to Rstudio, but i may be wrong... Agree on most points, and will be checking out the HTML org options as I mentioned. I did want to correct that slidify is not tied to rstudio, even though it integrates nicely with it. I was playing with it when straight from an R session within Emacs when I wrote the post. It also has some nice web publishing features to send the presentation right to git, dropbox, or rpubs from R, (though I didn't try that outside of rstudio, so there could be caveats). John rick
