Xaringan: Images with caption?

[pat-s]

Is there a simpler way than using HTML for this? fig.cap in knitr code chunks is not working in combination with knitr::include_graphics().

This is my html workaround:

<figure>
    <img src='/img/gdal-overview.png' />
    <font size="2">
    <figcaption> Abb.1: <a href= "http://r-spatial.org//2016/11/29/openeo.html">http://r-spatial.org//2016/11/29/openeo.html </a> 
    </figcaption>
    </font>
</figure>

[yihui]

I don't feel numbered image captions is a necessary feature in presentations. Presentations are for the speaker to explain in real time to the audience, and it is the speaker's responsibility to explain the figure clearly. If the audience have to read the figure caption in slides to understand what it means, it is probably a failure of the presenter. You may argue that someone missed the talk may want to read the slides afterwards. That is a valid reason, but I'd say that is not a strong reason. If everything can be made clear in slides, what is the meaning of presentations? Learning by reading slides is rarely a good idea in my opinion -- blog posts, tutorials, papers, and books would be much better way if someone wants to learn by _reading_. A presentation is to be listened to by definition.

For figure numbers, normally you number a figure because you want to refer to it on other pages (like "see Figure 5"). This is useful in papers and books, but for presentations, I think it is actually harmful, because you are adding burden to the audience. The audience don't have a copy of your slides at hand in many cases, so if you mention Figure 5 on a different slide, either you have to go back to the page of Figure 5, or the audience have to memorize your slides.

On the other hand, if I have to write a figure caption anyway, I'd just write a normal paragraph beneath the figure (perhaps centered), e.g.

![](foo.png)

.center[A figure caption.]

I don't see the significant benefits of using the <figure> tag. Personally I'm totally happy with a figure plus caption like this:

You don't have to agree with me, but given that 1) the door is not completely closed, meaning that you can write figure captions if you prefer (it is just the syntax is not Markdown); and 2) I don't see the significant gain by implementing certain Markdown syntax to support (numbered) figure captions, my conclusion is this feature is probably not going to be my priority. Note everything I said here is conditional on the fact that we are making presentations.

[pat-s]

Thanks for the extensive answer!

I agree fully that figure captions like in books do not make much sense in presentations, simply based on the points you already outlined (cross-references, "go back to slide xy").
And yes, learning from tutorials, blog posts and books is much more efficient.

The main argument I see for figure captions are image references. Most often one takes images from the web or from books and wants to cite the sources. It does not matter if you put a "Fig." in front of the URL/inline-ref which is following. With fig.cap enabled, one would have a consistent way of creating figure captions within a knitr code chunk rather than having always to switch to the html workaround.

I think this does not only apply to scientists but to all users who want to reference their images.

Imo this also enables the need of a Wiki page summarising all possibilities of inserting images (knitr, plain markdown, html) with their advantages and disadvantages. However, it would be great to have one option inheriting all possibilities.

Nevertheless, I understand that this has no (high) priority and is opinion based, so I´m fully ok with using the html workaround :) And thanks for clarification that the workaround is indeed needed.

[pat-s]

I found a simple markdown solution:

.center[

![My image](https://upload.wikimedia.org/wikipedia/commons/b/be/Sharingan_triple.svg)

.caption[
**Fig. 1:** Image caption
]

]

CSS:

.caption {
  text-align: center;
  font-size: .8rem;
}

@yihui Would you be fine with putting this CSS class into default.css?

[ekstroem]

Wouldn't a better solution be to have a R function that includes the image and adds the caption?

I haven't given this a lot of thought but that would make it easier to modify and tweak (from the presentation) rather than having to tinker with the css file?

[pat-s]

So you propose an R function incorporating the markdown image syntax including the caption patch here?
Idk how easy it would be to include a function within moon_reader() and if it isn't easier to just stick with the markdown approach.

What would also be a neat solution is to have the image caption within the [ ] of the markdown call, similar to the custom defined macros that resize the image (but idk if only JS code is executable there or any language, haven't taken a close look yet).

[ekstroem]

As said I haven't given this any real thought so I could be completely off.

That being said I mostly (only) include images using knitr::include_graphics() instead of standard markdown inclusion of images because that gives me more control (scaling etc). And I'm guessing it would be possible to create a version where captions could be added right away.

[jvcasillas]

I'm not sure if I follow. What exactly is the issue with fig.cap? That it doesn't produce numbered figures or that it doesn't work? It seems to work fine for me.

[pat-s]

Ah interesting! Seems there were some changes somewhere (knitr, rmarkdown) or I was doing something wrong when initially posting the issue :smile:

Still, I like the CSS solution as it enables changing the font size of the caption. Also it can be used with both the markdown and include_graphics() approach.

[pat-s]

I think this issue bundles a lot of approaches how captions can be achieved and we can close here :)

[jolars]

It seems like the fig.cap solution now only works with knitr::include_graphics() and not when plots are produced as in the second example in @jvcasillas example

[cderv]

@jolars if you found a new issue since 2018 the best thing to do is opened a new ticket here in GH and linked to this one if it is similar.
You can then provide a new reproducible examples with last versions of 📦 . Thank you !