tayaer.blogg.se

And they are not always trivial - that is, unless your name is Yihui Xie :) This sounds like a reasonable thing to ask, however, there are many ways in which this assumption can be broken. As an introductory disclaimer, this post is not an exhaustive guide but merely a retrospect on the issues I faced and how I tackled them when writing posts for this blog using blogdown.įor this post, we would consider an R Markdown document reproducible if we can be sure that it produces identical rendered output as long as the content of the Rmd document, the data used within it and the rendering function stay the same. In this post, I will list a few sources of reproducibility issues I came across and how I tried to solve them. One of the challenges that stay is reproducibility of the rendered results. This can help us immensely when presenting data science type of work to audiences, while still being able to version control the content creation process. ```) %>% mutate( mpg = cell_spec( mpg, color = 'white', bold = T, background = spec_color( 1 : 10, end = 0.9, option = 'viridis', direction = -1) )) %>% kable( format= 'html', escape = F, align = 'c') %>% kable_styling( c( 'condensed', 'basic'), full_width = F, position= 'left')įor interactivity and more options to play with, consider the DT package.R Markdown is a great tool to use for creating reports, presentations and even websites that contain evaluated and rendered code. In the following, all of these arguments might have an effect on the resulting image. You may specify the image output type, *.png or *.svg for example, with fig.dev. It might not have any discernible effect that you can actually see in the document depending on your default settings, but would allow viewers to zoom without loss of clarity, though they could do that with an svg image anyway. The option fig.retina will only work for HTML documents, and will scale your image such that it will “change the chunk option dpi to dpi * fig.retina, and out.width to fig.width * dpi / fig.retina internally for example, the physical size of an image is doubled and its display size is halved when fig.retina = 2”. What’s more, you can use them alongside fig.width and fig.height to ensure you’ll have utterly no idea what will be produced in the finished product. I also find that out.height actually does nothing in many cases. These out.* can also apply to PDF/ \(\LaTeX\) figures (but I can’t figure out why). There is also out.extra that will apply additional arguments (e.g. css/img styling). The out.width and out.height options are geared toward HTML-based visualization, and are expressed in pixels, or perhaps most usefully, percentages. You also have fig.align with options like ‘left’ and ‘center’, but it apparently has no effect on htmlwidgets and similar packages that rely on other languages like JavaScript. If expressing size in inches doesn’t make sense to you, you can use dpi, which will allow you to know think of dpi*inches as what to expect in terms of pixels. If you supply fig.dim with fig.asp, the latter will be ignored. There is also fig.dim, which will take the two values you would have specified for fig.width and fig.height.

#Rmarkdown cache plus

You can also supply fig.width plus fig.asp which will produce a height that is fig.width*fig.asp. Furthermore, these settings will not affect interactive and possibly other images in HTML documents except in unexpected ways 9. While you can use them in HTML for static images as those produced by ggplot2, there isn’t a reason I can think of to express the size in inches for an electronic display. Oddly, these are expressed in inches, but at least it is easy enough to manipulate to your liking. For non-HTML, the chunk options of fig.width and fig.height are generally used for figure dimensions.

#Rmarkdown cache pdf

To begin, there are different systems for PDF or MS Word vs. HTML-based documents. Why you should switch from your current approach.