Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Figure Captions with Multiple Figures and echo=FALSE Does not Print the Caption #1524

Open
billdenney opened this issue Mar 14, 2018 · 6 comments · May be fixed by #1760
Open

Figure Captions with Multiple Figures and echo=FALSE Does not Print the Caption #1524

billdenney opened this issue Mar 14, 2018 · 6 comments · May be fixed by #1760
Labels
feature Feature requests

Comments

@billdenney
Copy link

When printing multiple figures per chunk (and maybe in other scenarios with multiple outputs per chunk), figure captions do not show up unless extra line breaks are inserted between them. In the example below, the first and third chunks caption as expected, but the second does not. (This is similar to #820, but it still appears to be an issue.)

---
title: "Test2"
author: "William Denney"
date: "March 14, 2018"
output:
  pdf_document:
    keep_tex: yes
    fig_caption: yes
---

```{r setup, include=FALSE}
knitr::opts_chunk$set(echo = TRUE)
cap_vec <- c("howdy", "foo")
```


# With echo=TRUE

When `echo = TRUE`, the captions print as expected.

```{r fig.cap=cap_vec, echo=TRUE}
plot(pressure)
plot(temperature~1/pressure, data=pressure)
```

\clearpage

# With echo=FALSE

When `echo = FALSE`, the captions do not print.

```{r fig.cap=cap_vec, echo=FALSE}
plot(pressure)
plot(temperature~1/pressure, data=pressure)
```

\clearpage

# With echo=FALSE and new lines

When `echo= FALSE` and new lines are added between figures via cat, it works.

```{r fig.cap=cap_vec, echo=FALSE}
cat("\n\n")
plot(pressure)
cat("\n\n")
plot(temperature~1/pressure, data=pressure)
cat("\n\n")
```
@billdenney
Copy link
Author

On further looking, this has been previously reported: https://groups.google.com/forum/#!topic/knitr/MJVLiVyGCro

If there were a way to make this fix automatic, that would be beneficial. If not, perhaps it could be documented in more detail.

@billdenney
Copy link
Author

As a followup thought: Perhaps a simple knit_print method doing similar to the following would fix the issue. Since it has caused confusion for about 4 years (given the Google groups thread), it will probably continue to cause problems in the future, too.

knit_print.ggplot <- function(x, ..., inline=FALSE) {
  if (!inline) {
    cat("\n\n")
  }
  print(x, ...)
  if (!inline) {
    cat("\n\n")
  }
}

And then doing similar for base graphics and lattice so that they all use the same method. The real method would probably need to be more complex, but hopefully this general idea could help.

@jarad
Copy link

jarad commented May 18, 2020

@billdenney thanks for the solution

@cderv
Copy link
Collaborator

cderv commented Jan 27, 2021

@yihui I am not sure how to classify this one.

Currently, for LaTeX output when there is caption, we add a space after the markdown syntax so that it is not seen by Pandoc as a inline image.

res = paste0(res, if (nocap) '<!-- -->' else '', if (is_latex_output()) ' ' else '')

![cap](img/path) 

However, when there are several images in the same chunk and echo = FALSE, the chunk output will be wrap using hook plot with the syntax above, and results will be pasted on the same line. So we get

![cap1](path/img1) ![cap2](path/img2) 

This leads to no caption by Pandoc as seen as inline images.

This does not happen when echo = TRUE because the are some \n\n appended before and after a source code chunk.

This also happens with HTML output also.

Should we consider the addition of cat('\n\n') a solution for this case or could we add a new line in hook_plot_md() so that it does not happen ?

I am not sure of the potential effect of such change.

@cderv cderv added the feature Feature requests label Jan 27, 2021
@atusy
Copy link
Collaborator

atusy commented Jan 27, 2021

@cderv It seems the PR #1760 solves this problem.

@cderv
Copy link
Collaborator

cderv commented Jan 27, 2021

Oh great thanks @atusy ! I am going though old issues to make some triage and know what is in the backlog before looking at the PR. Aim is to match when possible! And you've just help me. Thank you!

I'll link these 2 so that we remember it will close.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature Feature requests
Projects
None yet
4 participants