* Proposal/request for input: slidify export for html slides
@ 2014-01-30 0:05 John Hendy
2014-01-30 0:57 ` Ahmadou Dicko
0 siblings, 1 reply; 18+ messages in thread
From: John Hendy @ 2014-01-30 0:05 UTC (permalink / raw)
To: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 1148 bytes --]
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
[-- Attachment #2: Type: text/html, Size: 1463 bytes --]
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: Proposal/request for input: slidify export for html slides 2014-01-30 0:05 Proposal/request for input: slidify export for html slides John Hendy @ 2014-01-30 0:57 ` Ahmadou Dicko 2014-01-30 1:45 ` Rick Frankel 0 siblings, 1 reply; 18+ messages in thread From: Ahmadou Dicko @ 2014-01-30 0:57 UTC (permalink / raw) To: John Hendy; +Cc: emacs-orgmode [-- Attachment #1.1: Type: text/plain, Size: 2509 bytes --] 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.hendy@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.dicko@ucad.edu.sn twitter : @dickoah github : github/dickoa <https://github.com/dickoa> tel : +221 33 827 55 16 portable: +221 77 123 81 69 [-- Attachment #1.2: Type: text/html, Size: 3267 bytes --] [-- Attachment #2: rChart.html --] [-- Type: text/html, Size: 7722 bytes --] [-- Attachment #3: rChart.org --] [-- Type: application/vnd.lotus-organizer, Size: 1218 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Proposal/request for input: slidify export for html slides 2014-01-30 0:57 ` Ahmadou Dicko @ 2014-01-30 1:45 ` Rick Frankel 2014-01-30 4:26 ` John Hendy 0 siblings, 1 reply; 18+ messages in thread From: Rick Frankel @ 2014-01-30 1:45 UTC (permalink / raw) To: emacs-orgmode On Thu, Jan 30, 2014 at 12:57:46AM +0000, 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Proposal/request for input: slidify export for html slides 2014-01-30 1:45 ` Rick Frankel @ 2014-01-30 4:26 ` John Hendy 2014-02-07 1:26 ` John Hendy 0 siblings, 1 reply; 18+ messages in thread From: John Hendy @ 2014-01-30 4:26 UTC (permalink / raw) To: emacs-orgmode [-- Attachment #1: Type: text/plain, Size: 1993 bytes --] On Jan 29, 2014 7:46 PM, "Rick Frankel" <rick@rickster.com> wrote: > > On Thu, Jan 30, 2014 at 12:57:46AM +0000, 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 > [-- Attachment #2: Type: text/html, Size: 2536 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Proposal/request for input: slidify export for html slides 2014-01-30 4:26 ` John Hendy @ 2014-02-07 1:26 ` John Hendy 2014-02-07 7:58 ` Andreas Leha 2014-02-07 21:50 ` Charles Berry 0 siblings, 2 replies; 18+ messages in thread From: John Hendy @ 2014-02-07 1:26 UTC (permalink / raw) To: emacs-orgmode 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.hendy@gmail.com> wrote: > > On Jan 29, 2014 7:46 PM, "Rick Frankel" <rick@rickster.com> wrote: >> >> On Thu, Jan 30, 2014 at 12:57:46AM +0000, 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 >> ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Proposal/request for input: slidify export for html slides 2014-02-07 1:26 ` John Hendy @ 2014-02-07 7:58 ` Andreas Leha 2014-02-07 21:50 ` Charles Berry 1 sibling, 0 replies; 18+ messages in thread From: Andreas Leha @ 2014-02-07 7:58 UTC (permalink / raw) To: emacs-orgmode Hi John, John Hendy <jw.hendy@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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Proposal/request for input: slidify export for html slides 2014-02-07 1:26 ` John Hendy 2014-02-07 7:58 ` Andreas Leha @ 2014-02-07 21:50 ` Charles Berry 2014-02-07 22:18 ` John Hendy 1 sibling, 1 reply; 18+ messages in thread From: Charles Berry @ 2014-02-07 21:50 UTC (permalink / raw) To: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Proposal/request for input: slidify export for html slides 2014-02-07 21:50 ` Charles Berry @ 2014-02-07 22:18 ` John Hendy 2014-02-08 1:04 ` Charles Berry 2014-02-08 9:33 ` Nicolas Goaziou 0 siblings, 2 replies; 18+ messages in thread From: John Hendy @ 2014-02-07 22:18 UTC (permalink / raw) To: Charles Berry; +Cc: emacs-orgmode [-- Attachment #1: Type: text/plain, Size: 3976 bytes --] On Fri, Feb 7, 2014 at 3:50 PM, Charles Berry <ccberry@ucsd.edu> wrote: > 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. > 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) #+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, waaaay 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" :) > 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. > I'll take a look at this. I wasn't aware of 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. > Understood, and inserting the yaml header is not an issue at all. The #+md: --- code alone removes a good amount of effort. 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. Do I need to define a center <div> style? I googled around for the proper syntax to center images in markup and didn't find much other than defining a .css style to go along with the description. In this case, it seems Org defaults to [nil] so I'd either replace all of those or .css style all of the [nil]. - http://stackoverflow.com/questions/255170/markdown-and-image-alignment (just change the =float : right= argument to centering syntax) Thanks for the input, John > > HTH, > > Chuck > > > > [-- Attachment #2: world.pdf --] [-- Type: application/pdf, Size: 132480 bytes --] [-- Attachment #3: world-adj.pdf --] [-- Type: application/pdf, Size: 132478 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Proposal/request for input: slidify export for html slides 2014-02-07 22:18 ` John Hendy @ 2014-02-08 1:04 ` Charles Berry 2014-02-08 5:38 ` John Hendy 2014-02-08 9:33 ` Nicolas Goaziou 1 sibling, 1 reply; 18+ messages in thread From: Charles Berry @ 2014-02-08 1:04 UTC (permalink / raw) To: emacs-orgmode 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, waaaay 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Proposal/request for input: slidify export for html slides 2014-02-08 1:04 ` Charles Berry @ 2014-02-08 5:38 ` John Hendy 2014-02-08 5:51 ` John Hendy 0 siblings, 1 reply; 18+ messages in thread From: John Hendy @ 2014-02-08 5:38 UTC (permalink / raw) To: Charles Berry; +Cc: emacs-orgmode [-- Attachment #1: Type: text/plain, Size: 3770 bytes --] On Fri, Feb 7, 2014 at 7:04 PM, Charles Berry <ccberry@ucsd.edu> wrote: > 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] > [snip] >> 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. Indeed. I've had to deal with that when exporting to html. Was just curious if there was a more elegant way, and it seems there's not, but I suppose it's just adjusting syntax from #+attr_latex stuff to the knitr equivalents, which isn't bad to know anyway since I've been working more with RStudio. [snip] >> 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.) Thanks for the reference. > > [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. > 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? I'm also getting some odd code highlighting (see attached). Every once in a while, it's like it can't differentiate non strings (black) from strings (red)? Any idea why that might be? I still have some attr_latex stuff to prune out, so perhaps that's gunking up proper code recognition... then again, any of my latex options shouldn't be touching the contents of ```{r} chunks, so I'm perplexed. Other than that and figuring out my plot/image strategy, I think this will work wonderfully! I won't be able to transition my slides to Slidify by tomorrow, but am quite hopeful for transitioning in the future! Love the idea of embedding shiny apps or d3 right in a presentation vs. having to open a browser :) Also makes it so much easier to share presentations, embed them in a web page, or whatnot. No more things like relying on box/dropbox/google drive to have in-browser PDF displays! Thanks so much for chiming in -- I'd not seen ox-ravel before and am really glad to have discovered it! John > > HTH, > > Chuck > > > > [-- Attachment #2: 2014-02-07_233046.png --] [-- Type: image/png, Size: 36771 bytes --] [-- Attachment #3: 2014-02-07_233122.png --] [-- Type: image/png, Size: 80355 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Proposal/request for input: slidify export for html slides 2014-02-08 5:38 ` John Hendy @ 2014-02-08 5:51 ` John Hendy 2014-02-08 17:18 ` Charles Berry 0 siblings, 1 reply; 18+ messages in thread From: John Hendy @ 2014-02-08 5:51 UTC (permalink / raw) To: Charles Berry; +Cc: emacs-orgmode On Fri, Feb 7, 2014 at 11:38 PM, John Hendy <jw.hendy@gmail.com> wrote: > On Fri, Feb 7, 2014 at 7:04 PM, Charles Berry <ccberry@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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Proposal/request for input: slidify export for html slides 2014-02-08 5:51 ` John Hendy @ 2014-02-08 17:18 ` Charles Berry 2014-02-09 22:26 ` John Hendy 0 siblings, 1 reply; 18+ messages in thread From: Charles Berry @ 2014-02-08 17:18 UTC (permalink / raw) To: emacs-orgmode 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Proposal/request for input: slidify export for html slides 2014-02-08 17:18 ` Charles Berry @ 2014-02-09 22:26 ` John Hendy 2014-02-10 4:16 ` Charles Berry 0 siblings, 1 reply; 18+ messages in thread From: John Hendy @ 2014-02-09 22:26 UTC (permalink / raw) To: Charles Berry; +Cc: emacs-orgmode On Sat, Feb 8, 2014 at 11:18 AM, Charles Berry <ccberry@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. > > ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Proposal/request for input: slidify export for html slides 2014-02-09 22:26 ` John Hendy @ 2014-02-10 4:16 ` Charles Berry 2014-02-10 4:54 ` John Hendy 0 siblings, 1 reply; 18+ messages in thread From: Charles Berry @ 2014-02-10 4:16 UTC (permalink / raw) To: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Proposal/request for input: slidify export for html slides 2014-02-10 4:16 ` Charles Berry @ 2014-02-10 4:54 ` John Hendy 0 siblings, 0 replies; 18+ messages in thread From: John Hendy @ 2014-02-10 4:54 UTC (permalink / raw) To: Charles Berry; +Cc: emacs-orgmode On Sun, Feb 9, 2014 at 10:16 PM, Charles Berry <ccberry@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 > > ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Proposal/request for input: slidify export for html slides 2014-02-07 22:18 ` John Hendy 2014-02-08 1:04 ` Charles Berry @ 2014-02-08 9:33 ` Nicolas Goaziou 2014-02-08 14:11 ` John Hendy 1 sibling, 1 reply; 18+ messages in thread From: Nicolas Goaziou @ 2014-02-08 9:33 UTC (permalink / raw) To: John Hendy; +Cc: emacs-orgmode, Charles Berry Hello, John Hendy <jw.hendy@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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Proposal/request for input: slidify export for html slides 2014-02-08 9:33 ` Nicolas Goaziou @ 2014-02-08 14:11 ` John Hendy 2014-02-08 14:52 ` Nicolas Goaziou 0 siblings, 1 reply; 18+ messages in thread From: John Hendy @ 2014-02-08 14:11 UTC (permalink / raw) To: Nicolas Goaziou; +Cc: emacs-orgmode, Charles Berry [-- Attachment #1: Type: text/plain, Size: 562 bytes --] On Feb 8, 2014 3:32 AM, "Nicolas Goaziou" <n.goaziou@gmail.com> wrote: > > Hello, > > John Hendy <jw.hendy@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 [-- Attachment #2: Type: text/html, Size: 935 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Proposal/request for input: slidify export for html slides 2014-02-08 14:11 ` John Hendy @ 2014-02-08 14:52 ` Nicolas Goaziou 0 siblings, 0 replies; 18+ messages in thread From: Nicolas Goaziou @ 2014-02-08 14:52 UTC (permalink / raw) To: John Hendy; +Cc: emacs-orgmode, Charles Berry John Hendy <jw.hendy@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 ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2014-02-10 4:54 UTC | newest] Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-01-30 0:05 Proposal/request for input: slidify export for html slides John Hendy 2014-01-30 0:57 ` Ahmadou Dicko 2014-01-30 1:45 ` Rick Frankel 2014-01-30 4:26 ` John Hendy 2014-02-07 1:26 ` John Hendy 2014-02-07 7:58 ` Andreas Leha 2014-02-07 21:50 ` Charles Berry 2014-02-07 22:18 ` John Hendy 2014-02-08 1:04 ` Charles Berry 2014-02-08 5:38 ` John Hendy 2014-02-08 5:51 ` John Hendy 2014-02-08 17:18 ` Charles Berry 2014-02-09 22:26 ` John Hendy 2014-02-10 4:16 ` Charles Berry 2014-02-10 4:54 ` John Hendy 2014-02-08 9:33 ` Nicolas Goaziou 2014-02-08 14:11 ` John Hendy 2014-02-08 14:52 ` Nicolas Goaziou
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs/org-mode.git 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).
![[-- Attachment #2: 2014-02-07_233046.png --] [-- Type: image/png, Size: 36771 bytes --]](../../CA+M2ft_mZtwvTpScZ=hQX50_dKQicxnmn0AWNYVarzodeMW7qQ@mail.gmail.com/2-2014-02-07_233046.png){kind=link}
![[-- Attachment #3: 2014-02-07_233122.png --] [-- Type: image/png, Size: 80355 bytes --]](../../CA+M2ft_mZtwvTpScZ=hQX50_dKQicxnmn0AWNYVarzodeMW7qQ@mail.gmail.com/3-2014-02-07_233122.png){kind=link}