Equivalent of "highly dynamic" appearance in markdown presentations - rstudio

I am considering making my presentations using markdown in RStudio rather than beamer. In beamer I often use incremental appearance of the content, with the option "highly dynamic", which makes the next item to appear show in light gray before appearing fully. Apart from looking nice, this helps me present as it prevents me from being surprised if I forget the next point on the slide.
My question is: Is there any way to achieve a similar effect if I make my slides in RStudio, for instance as an R presentation, or rmarkdown presentation using ioslides, or Slidy?
I am aware that I can set incremental: true in R presentations, but this only gives incremental appearance, not the "highly dynamic" effect.

There are several different ways to produce slides in RMarkdown: ioslides, slidy, revealjs, xaringan, etc. I tend to use ioslides, and this method works there. I have added a couple of other
variations below.
What you need to do is to change the CSS for the selector .build .to-build so that instead of making items transparent, it only makes them partially transparent. You can do this by creating a file containing this:
.build .to-build {
opacity: 0.1
}
If you call that file incremental.css, then in your YAML for the presentation, you have this:
output:
ioslides_presentation:
incremental: true
css: incremental.css
Then you will see something like this when you display the sample presentation after showing the first bullet:
Edited to add:
Here's the CSS to use if you're using slidy_presentation instead of ioslides_presentation:
body.single_slide .invisible {
opacity: 0.1;
visibility: visible;
}
And here's what to use for revealjs::revealjs_presentation:
.reveal .slides section .fragment {
opacity: 0.1;
visibility: visible;
}
You can probably put all three recipes into the incremental.css file, and then switch between the formats until you find which one you like best.

If you are making beamer presentations from Rmarkdown, this works:
---
output:
beamer_presentation:
incremental: true
header-includes:
- \setbeamercovered{highly dynamic}
---
- one
- two
- three

Related

adjusting RMarkdown Themes

I have an R Markdown Document i want to embed in a shiny app based on the prettydoc engine. I have seen a tutorial about using the cayman theme for my document. The problem is i want to change the gradient in the header to be sunkist based on the gradient sheet here. Does anyone know how to achieve this. Is it a setting in the YAML
In the example supplied you type something like
---
title: Nineteen Years Later
author: Harry Potter
date: July 31, 2016
output:
prettydoc::html_pretty:
theme: cayman
highlight: github
---
An Additional information on the cayman theme can be found here
Changing the theme in YAML will not achieve what you intend to do. These themes are prebuilt and unless one of them already have the Sunskit gradient set, the outcome won't be what you desire.
An alternate approach would be to make the change in the stylesheet of the theme. For example:- In the cayman theme, you could open the cayman.css and this to the bottom.
.page-header {
background-color: #F2994A; /* fallback for old browsers */
background-image: -webkit-linear-gradient(to right, #F2C94C, #F2994A);
background-image: linear-gradient(to right, #F2C94C, #F2994A);
}
This would change the gradient in the header.

Bold code in rst

How can I get code (monospace) text that is bold in rst (I'm using Sphinx)? Anything in :: seems to be rendered literally, as with ``, so ``**bold**`` doesn't work.
In general, nested inline markup is not possible in reStructuredText. There are more or less ugly workarounds, such as using raw HTML. Like this:
.. raw:: html
<div>Some stuff <pre>some <b>bold</b> text</pre>...</div>
Actually using raw for code is a very bad thing to do as it ignores the beautiful Pygments highlighting and complicates things to extreme. First thing to do is to play with different Pygments highlighting styles. You can find a functional demo here. Then you may set the appropriate highlighting in conf.py. If none of the styles make the desired part of your code bold, you may consider creating your own Pygments theme, which is unfamiliar territory for me, but shouldn't be that hard.
There is third thing to try though, you could look up the class of the word you need to highlight and add a rule to your CSS. Pygments produce this seemingly gibberish classes like nv, ls, etc for every type of the highlighted words. But keep in mind, that every instance of this type will be highlighted. If your chosen word is a class definition - all class definitions will be highlighted.
Only if none of these options apply should you consider using something as atrocious as raw, because every time someone uses raw, Sphinx dies a little. Do you really want Sphinx to die?
Most likely restructured text does not support formatting options you are asking for.
However you are free to add your own :: admonition directives which have custom CSS styling over them.
Example for a custom block and CSS styling. RST:
.. admonition:: foobar
My custom text here
CSS:
.admonition-foobar {
font-weight: bold;
}

Block elements overlapping with singularitygs

I'm doing my first project with singularity grid system and I'm loving it so far. However, I'm having a strange problem in a section where I have an <h2> and <h3> elements overlapping... really having an hard time figuring what's the problem.
My project in development is available at:
http://senseslabv3.brunomonteiro.mixture.io/
First <section> with class=intro.
Does anyone have a clue about it's going on?
Thanks for your time.
As the others have said, you need to clear your floats. By default, Singularity's output style is "Isolation" which requires a knowledge of how floats should get cleared (clear: left, clear: right, clear: both, clear: none). Singularity assumes no clear (clear: none) which means that grid items may overlap if not properly cleared. It does this to adhere to the most common mental model for the Isolation output method, specifically placing blocks at a discrete point on the grid. Clearing your floats will clear them to an item's margin edge, most visibly by creating new rows. See the Mozilla Developer Network article on Clear.
Note, clearing your floats and clearfixing as proposed by lolmaus actually do different things. Clearing your float will clear items to margin edges, whereas clearfixing an item will ensure that all of its floated children are properly contained.
The Float output adheres to a different mental model, one of walking across a row of your grid, and therefore automatically clears your floats for you. If you'd prefer to use the Float output style as your default, simply add $output: 'float' to your Sass file before calling your grid. This will change your global output style context. Alternatively, you can use float-span to use the Float output style mental model and output on-demand instead of grid-span, or pass $output-style: 'float' as an option to grid-span.
Take a look at the documentation for Output Styles, Output Span, Float Span, and Context Overrides in grid-span for a deeper dive into the different output styles and options available in Singularity.
Clear both needs to be declared somewhere below your grid-span mixin .tag h3 {clear: both;}
instead of the ugly <div style="clear: both;"></div> consider this:
.intro h2 {
#include pie-clearfix; }
Or, if you use toolkit:
.intro h2 {
#extend %clearfix-micro; }
We might better address your problem if you share your SASS code.
This is an old question but I just ran into the problem. Snugug's answer worked perfect but I wanted to show the code that worked for me. (Couldn't put code in a comment)
//Main content container
.l-main {
#include breakpoint(80em) {
#include grid-span(16, 3, 20);
}
}
// A full width banner inside content container. I needed this to clear because there are several other smaller columns/grids above and below the banner.
.b-banner {
#include breakpoint(80em) {
#include float-span(16, 1, last);
}
}

How to set size for local image using knitr for markdown?

I have a local image that I would like to include in an .Rmd file which I will then knit and convert to HTML slides with Pandoc. Per this post, this will insert the local image :
![Image Title](path/to/your/image)
Is there a way to modify this code to also set the image size?
The question is old, but still receives a lot of attention. As the existing answers are outdated, here a more up-to-date solution:
Resizing local images
As of knitr 1.12, there is the function include_graphics. From ?include_graphics (emphasis mine):
The major advantage of using this function is that it is portable in the sense that it works for all document formats that knitr supports, so you do not need to think if you have to use, for example, LaTeX or Markdown syntax, to embed an external image. Chunk options related to graphics output that work for normal R plots also work for these images, such as out.width and out.height.
Example:
```{r, out.width = "400px"}
knitr::include_graphics("path/to/image.png")
```
Advantages:
Over agastudy's answer: No need for external libraries or for re-rastering the image.
Over Shruti Kapoor's answer: No need to manually write HTML. Besides, the image is included in the self-contained version of the file.
Including generated images
To compose the path to a plot that is generated in a chunk (but not included), the chunk options opts_current$get("fig.path") (path to figure directory) as well as opts_current$get("label") (label of current chunk) may be useful. The following example uses fig.path to include the second of two images which were generated (but not displayed) in the first chunk:
```{r generate_figures, fig.show = "hide"}
library(knitr)
plot(1:10, col = "green")
plot(1:10, col = "red")
```
```{r}
include_graphics(sprintf("%sgenerate_figures-2.png", opts_current$get("fig.path")))
```
The general pattern of figure paths is [fig.path]/[chunklabel]-[i].[ext], where chunklabel is the label of the chunk where the plot has been generated, i is the plot index (within this chunk) and ext is the file extension (by default png in RMarkdown documents).
Un updated answer: in knitr 1.17 you can simply use
![Image Title](path/to/your/image){width=250px}
edit as per comment from #jsb
Note this works only without spaces, e.g. {width=250px} not {width = 250px}
You can also read the image using png package for example and plot it like a regular plot using grid.raster from the grid package.
```{r fig.width=1, fig.height=10,echo=FALSE}
library(png)
library(grid)
img <- readPNG("path/to/your/image")
grid.raster(img)
```
With this method you have full control of the size of you image.
Here's some options that keep the file self-contained without retastering the image:
Wrap the image in div tags
<div style="width:300px; height:200px">
![Image](path/to/image)
</div>
Use a stylesheet
test.Rmd
---
title: test
output: html_document
css: test.css
---
## Page with an image {#myImagePage}
![Image](path/to/image)
test.css
#myImagePage img {
width: 400px;
height: 200px;
}
If you have more than one image you might need to use the nth-child pseudo-selector for this second option.
If you are converting to HTML, you can set the size of the image using HTML syntax using:
<img src="path/to/image" height="400px" width="300px" />
or whatever height and width you would want to give.
Had the same issue today and found another option with knitr 1.16 when knitting to PDF (which requires that you have pandoc installed):
![Image Title](path/to/your/image){width=70%}
This method may require that you do a bit of trial and error to find the size that works for you. It is especially convenient because it makes putting two images side by side a prettier process. For example:
![Image 1](path/to/image1){width=70%}![Image 2](path/to/image2){width=30%}
You can get creative and stack a couple of these side by side and size them as you see fit. See https://rpubs.com/RatherBit/90926 for more ideas and examples.
Another option that worked for me is playing with the dpi option of knitr::include_graphics() like this:
```{r}
knitr::include_graphics("path/to/image.png", dpi = 100)
```
... which sure (unless you do the math) is trial and error compared to defining dimensions in the chunk, but maybe it will help somebody.
The knitr::include_graphics solution worked well for resizing the figures, but I was unable to figure out how to use it to produce side-by-side resized figures. I found this post useful for doing so.

Possible to create a conditional loop in Sass/Compass (with Middleman) based upon availability of (SVG) images?

Is it possible to create a conditional loop in Sass/Compass (with Middleman) based upon availability of (SVG) images?
I have upto 150 images (svg), each will be used as a background to a navigation link. However, the numbers of the images are non-continual, meaning some breaks. For example, there is 1.svg, 2.svg, 4.svg (with 3.svg missing). This happens throughout.
Now I could create a loop that just covers all eventualities:
#for $i from 1 through 150 {
.icon_#{$i} {
background-image: inline-image("svg/#{$i}.svg");
}
}
If I compile ordinarily whilst it produces excess CSS code (rules for images that don't exist) this does the job.
However, Middleman throws an error using this 'cover all' loop and won't compile the CSS if the image is missing (fair enough). And that got me thinking…
As Compass has image helpers, is there additional logic I could add that only produces the styles if the image exists? My first thought was using the Compass image-width() helper (e.g. if width == 0 don't continue) however, this won't work with SVGs.
Can anyone think of a way of doing this? Or is it simply implausible?
With a little knowledge of Ruby, you can adapt this existing solution to do what you want:
https://stackoverflow.com/a/10456412/901944
You could add a sass variable at the top before the loop and declare all the image numbers. ie:
$svgs: 1, 2, 4, 15, ... 150
Then your loop would be:
#for $i in $svgs {
.icon_#{$i} {
background-image: inline-image("svg/#{$i}.svg");
}
}
It's not the greatest solution as I'm sure you don't really want to enter in up to 150 numbers. Plus it's not very maintainable. But it's an option.

Resources