search

ramnathv / slidify

Generate reproducible html5 slides from R markdown
http://www.slidify.org
844 stars 339 forks source link

Options #77

Closed kafka399 closed 12 years ago

kafka399 commented 12 years ago

I would like to try framework option, however html output is always the same (grey). Is the syntax correct?

slidify('presentation.Rmd',options=list(framework='deck.js'))

ramnathv commented 12 years ago

Due to some updates I am making, the framework option is broken. I will push an update soon that will fix it.

kafka399 commented 12 years ago

Do you an idea how long it will take? If it is going to take more than 1-2 days, then I have to roll back to pandoc :(

ramnathv commented 12 years ago

If you can tell me which framework, you would like to work with, I can prioritize the fix. Currently two frameworks work - html5slides and io2012. I should have all of them fixed within a day, but just in case it takes time, I can at least fix the ones you need.

kafka399 commented 12 years ago

Well, I was going to test frameworks, which are not available in pandoc, for example deck.js. Nevertheless, if it is going to take one day, I can wait.

ramnathv commented 12 years ago

I got deck.js working. Try it out. For now, you would also have to pass the theme and transition options explicitly, since I have not included it in the defaults.

So you would do

slidify('presentation.Rmd',
  options=list(framework='deck.js', theme = 'swiss', transition = 'horizontal-slide'))

Let me know if it works, since I did a quick fix and have not tested it adequately.

ramnathv commented 12 years ago

BTW. pandoc does support multiple frameworks, although it doesn't call them that. It supports dzslides, slidy, beamer and slideous. slidify supports a lot more frameworks, and provides an option to invoke beamer using pandoc. I try keeping the design of slidify compatible with pandoc and eventually plan to provide an option that will allow you to process your deck using pandoc instead of the default.

ramnathv commented 12 years ago

Also, note that <h2> becomes slide titles in deck.js, while <h1> becomes big centered title. HTML5 Slides uses <h3> for slide title and <h2> and <h1> for middle titles. This makes it a little more difficult in going between frameworks.

kafka399 commented 12 years ago

I got blank page. How I suppose to install swiss theme? This directory is missing:

/home/user/R/x86_64-pc-linux-gnu-library/2.15/slidify/libraries/html5slides/swiss/

How do I build self contained html with slidify? Can it download images from internet, if markdown indicates that?

kafka399 commented 12 years ago

I would be happy with default version of slidify (html5slides) with rounded corners, however I can't stand, what header of any slide is in the middle of page. It is even worse, when graph is added. You can try to build my presentation to see the issue.

ramnathv commented 12 years ago

The problem is not slidify but the default styling of html5slides. As mentioned in my note previously, <h3> tags are styled as slide titles on top, while <h1> is styled as big center title. There are two possible solutions.

  1. Use h3 tags like this for slide titles in markdown ### Title
  2. Modify assets/templates/slide.tpl to this.
<h2>{{{ title }}}</h2>
{{{ content }}}

Let me know if either one of the two work for you.

ramnathv commented 12 years ago

The other issue I see with your presentation is that you are not using a --- to separate slides. The usage is pandoc compatible so you can always revert back to pandoc should you choose to. slidify automatically inserts separators when you use ATX style headers in markdown (### title). You are using SETEXT style headers, so that will not work currently.

kafka399 commented 12 years ago

Sorry, github doesn't host the latest version, but on local I have presentation with ---

ramnathv commented 12 years ago

Okay. Then you just need to follow one of the two approaches I suggested. A third approach would be to post process the presentation html and run

old <- readLines('presentation.html')
new <- gsub('<h1>', '<h2>', old)
new <- gsub('</h1', '</h2>', new)
writeLines(new, 'presentation.html')
kafka399 commented 12 years ago

I manage to run deck.js version - thank you. I hope, that in the future it will be much easier to build a presentation with slidify :)

ramnathv commented 12 years ago

I appreciate your feedback. Can you tell me what things could be simplified to make it easier building presentations with slidify?

kafka399 commented 12 years ago
ramnathv commented 12 years ago

Thanks for your feedback.

  1. Once the API stabilizes, I will provide a built version of the package so that Windows user don't have to bother with RTools. Once it is on CRAN, the build process will be automatically taken care of.
  2. You can ignore the --- if your slide headers are always the same header level and you use ATX style headers. It is harder parsing patterns from SETEXT style headers, which is what you are using. In any case, I will make it more clear in the documentation.
  3. Given the number of js and css files involved, having everything inline in one document will make the html file really big and slow to load. I do have an option embed = TRUE which inlines local images, user defined css/ js and serves all other system js and css files from a CDN. Using this option ensures that you can share the html file with anyone and they can view it as long as they are online.
  4. Use embed = TRUE. It will inline local images as base 64 encoded data.

I did not understand what you mean by "default output is a mess". If you author the slides according to the rules of the slide generation framework, then no manual intervention will be needed. For example, if you are using deck.js , <h1> tags become centered titles, while <h2> tags become top titles.

The fact that different frameworks use different conventions makes it a little messy and I am trying to add some glue to slidify so that it provides a consistent set of authoring rules across frameworks. Meanwhile, I will put together framework specific authoring rules that would help.

If you can further clarify what you mean by "messy output", I will appreciate that.

piccolbo commented 12 years ago

As far as the number of files, I think the RStudio guys pulled that one off for their publishing feature. Not sure it's exactly the same problem, but maybe some ideas can be borrowed. Announced in 0.96. +1 for single file.

ramnathv commented 12 years ago

Right now, it is possible to output a single file by adding the option embed = TRUE. Adding this option (a) embeds all images, (b) embeds all custom css and js and (c) serves all other css and js files needed by the framework/highlighter from Google Code. You can share the single file by uploading it to RPubs.

Now, even thought it is single file, it is not viewable offline since it still has dependencies. Embedding all JS and CSS is easy, but will make the file size larger, and based on what I have read, will make the file slow to load, since the browser will not cache anything. The advantage of linking css and js files is that the browser caches static assets thereby making page loads faster. I need to think about that one before I implement it.

piccolbo commented 12 years ago

This is a great step forward, but one can not assume to have Internet every time he's speaking somewhere, at least in my experience.

ramnathv commented 12 years ago

Well, when you are the speaker, the slide folder is what you would be presenting from, as it is self contained offline. I will work on providing an offline single file option, but I am not sure how efficient it would be, and how big the resulting html files would be.

piccolbo commented 12 years ago

My misunderstanding, I though that folder or single file Google Code had to be accessible. The way you put it it seems like an acceptable compromise.

ramnathv commented 12 years ago

I need to document things better, which is on my agenda. Just to make sure we have it right, if you want to have a version of the presentation that you can use offline, use copy_libraries = TRUE , so that all library files are copied to your slide folder and it is self contained (everything except for mathjax, which is a huge download).

Using embed = TRUE only embeds local images, css and js, serving framework/highlighter assets from Google Code CDN, which requires access to the internet.

piccolbo commented 12 years ago

So if I am giving a presentation and I have no internet connection, which is the norm because of security restrictions, I am not going to be able to show any math? I know it's stupid but very often the speaker is the only one not on line. I am fine if mathjax is shared among all my presentations, but there has to be a way. And those options, you are naming them based on how you implement thing, not what the user needs. I'd rather have a single.file option or an off line option and how you do it is your secret sauce. It's both more abstract and user friendly.

ramnathv commented 12 years ago

I don't want to package mathjax with slidify since it will make the package size really huge. You can always download mathjax and serve mathjax.js locally. I agree that the options will have to be base on a user's perspective and future versions of slidify will try to address them.

piccolbo commented 12 years ago

Does it mean I have to run a webserver and edit each document based on my configuration? Look at the installation page: http://www.mathjax.org/docs/2.0/installation.html How many statisticians will go though this (more than 2000 words), or go back to powerpoint? Wild guesses are acceptable. When you say that it will make the package bigger, nobody is questioning that. The issue here is that size is not the overarching consideration, ease of use and reliability are. By the way, I just downloaded it, it's 9.5MB compressed. It's a penny of SSD storage. It's like one high res picture. What is the problem?

On Sat, Jul 28, 2012 at 7:01 PM, Ramnath Vaidyanathan < reply@reply.github.com

wrote:

I don't want to package mathjax with slidify since it will make the package size really huge. You can always download mathjax and serve mathjax.js locally. I agree that the options will have to be base on a user's perspective and future versions of slidify will try to address them.

Reply to this email directly or view it on GitHub: https://github.com/ramnathv/slidify/issues/77#issuecomment-7349201

ramnathv commented 12 years ago

Let me explain the issue a little more in detail. If you are merely looking at things from the presenter's point of view, the best way to go about things is an offline option where every single css and js file is served from the slide folder. This is the easiest to implement since file size is no longer a limitation.

If you want to share your presentation with others, there are two options. Option 1 is to zip up your local slide folder (or put it up on github), but is not a preferred option for many as they don't want to go about emailing files > 10 MB in size. Option 2 is to serve all system css and js (including mathjax) files from a CDN and embed all local assets (images, css and js), so that you can share just a single html file which will work online only.

The pain point is when you want to share a single html file that will work offline. Now suddenly, everything has to be embedded in the file which makes the file size really large and defeats the entire purpose of html presentations.

The niggling question to me has been what options to offer (i would prefer a minimal set out-of-the-box and let users configure any custom setups they want) and the external assets that come with slidify (since there are quite a few).

As for mathjax, I realized I can follow RStudio and install a minimal version of mathjax for offline previews. Some documentation can take care of how to use the full version should people choose to.

ramnathv commented 12 years ago

I am not sure where your comment disappeared @piccolbo , but you make an interesting point. I fully agree with your view that for slidify to be usable, math should work out of the box, with minimal configuration.

The trouble is that mathjax uncompressed is around 26.5 MB and I am still not sure if a file size that large would be good for sharing. Even RStudio only provides a minimal mathjax installation for offline previews (which essentially removes image fonts that allow rendering in old-time browsers), which weighs at about 3.2 MB, that seems manageable.

In the next version of slidify that I will push to github, I am implementing a more general idea of widgets, which are extensions that work out of the box. mathjax will be one of them and I will build offline support using the same minimal installation used by the Rstudio folks.

piccolbo commented 12 years ago

I didn't think my tone was very constructive and I deleted it. I am squarely against sharing slides, I think it actually kills culture ( http://www.norvig.com/Gettysburg/sld001.htm) and even people ( https://www.edwardtufte.com/bboard/q-and-a-fetch-msg?msg_id=0001yB). This is a bigger discussion than saving two pennies worth of storage or supporting IE6 and I think beyond the scope of this issue.

On Sun, Jul 29, 2012 at 12:15 PM, Ramnath Vaidyanathan < reply@reply.github.com

wrote:

I am not sure where your comment disappeared @piccolbo , but you make an interesting point. I fully agree with your view that for slidify to be usable, math should work out of the box, with minimal configuration.

The trouble is that mathjax uncompressed is around 26.5 MB and I am still not sure if a file size that large would be good for sharing. Even RStudio only provides a minimal mathjax installation for offline previews (which essentially removes image fonts that allow rendering in old-time browsers), which weighs at about 3.2 MB, that seems manageable.

In the next version of slidify that I will push to github, I am implementing a more general idea of widgets, which are extensions that work out of the box. mathjax will be one of them and I will build offline support using the same minimal installation used by the Rstudio folks.

Reply to this email directly or view it on GitHub: https://github.com/ramnathv/slidify/issues/77#issuecomment-7355583

ramnathv commented 12 years ago

No problems. I see your point, but it depends on the reason you are putting together the slides in the first place. My motivation for slidify actually stemmed from teaching needs where I was frustrated at my inability to embed videos, demos etc. easily in the lecture slides that I share with my students. slidify was an attempt at making it easier for me to write interactive slide decks, which would allow me to easily embed the wealth of external content available for use. One might argue why not use hyperlinks for external content, but it is a major distraction from a pedagogical standpoint of having to switch from one mode to another. Here is a deck that illustrates the point I am making.