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

auto_pdf option not working #1587

Closed
davibicudo opened this issue Aug 7, 2018 · 6 comments
Closed

auto_pdf option not working #1587

davibicudo opened this issue Aug 7, 2018 · 6 comments
Milestone

Comments

@davibicudo
Copy link

davibicudo commented Aug 7, 2018

It seems setting the global auto_pdf option is not working. The resulting pdf is always preferring the pdf file when available and completely ignoring the global option.

Here is a self-contained test:

---
title: "knitr.graphics.auto_pdf issue"
output: pdf_document
---

```{r setup, include=FALSE}
options(knitr.graphics.auto_pdf = FALSE)
knitr::opts_chunk$set(fig.pos = 'htbp')
```


```{r, bug-file, echo=FALSE, results='hide'}
v <- sample(5, 1000, replace = T)
pdf(file="bug1.pdf")
hist(v)
dev.off()
png(file="bug1.png")
hist(v)
dev.off()
png(file="bug2.png")
plot(sort(v))
dev.off()
```
```{r, opts, echo=T}
getOption("knitr.graphics.auto_pdf")
```

```{r, bug1-include, echo=T, fig.asp = 0.5, fig.width = 4, fig.align = 'center', fig.cap="Unexpected pdf"}
knitr::include_graphics("./bug1.png", dpi = 200)
```


```{r, bug2-include, echo=T, fig.asp = 0.5, fig.width = 4, fig.align = 'center', fig.cap="Expected png"}
knitr::include_graphics("./bug2.png", dpi = 200)
```
@yihui
Copy link
Owner

yihui commented Aug 7, 2018

Since I don't use the filename extension:

res = sprintf('\\includegraphics%s{%s} ', size, sans_ext(x))
LaTeX may prefer .pdf over .png when both are present. There must be LaTeX tricks to reorder the preferences. Then you can use the includes: in_header option to apply the trick.

I may use the full filename with the extension, but I don't really remember why I didn't. This line of code should be seven years old now.

@davibicudo
Copy link
Author

davibicudo commented Aug 8, 2018

You seem to have changed it here eb89efe#r4907995

Wouldn't it be straightforward to switch the order of \DeclareGraphicsExtensions{.pdf,.png,.jpg} (put pdf at the end perhaps) in the generated tex when auto_pdf is set to FALSE?
Also, it seems by default LaTeX should pick png first anyway. Also from the SE post, perhaps the grfext package could help solve this.

By the way, it isn't clear to me when the auto_pdf plays a role if this issue is happening, although it seems it does. I just couldn't use the option at all.

@yihui yihui closed this as completed in 5dce2af Aug 10, 2018
@yihui
Copy link
Owner

yihui commented Aug 10, 2018

The commit you pointed out didn't really change it. x[1] and sans_ext(x) were the same thing (filename without extension).

I added a global option to support the full filename. You can set options(knitr.include_graphics.ext = TRUE). Thanks!

@yihui yihui added this to the v1.21 milestone Aug 10, 2018
yihui referenced this issue Aug 10, 2018
…n hook_plot_foo()

x is just the filename now; c(basename, ext) was largely for the convenience of LaTeX \includegraphics{}
@davibicudo
Copy link
Author

davibicudo commented Aug 13, 2018

Perfect, thanks a lot!

After testing I understood that if I use the options(knitr.include_graphics.ext = TRUE), then the knitr.graphics.auto_pdf works as expected. That means for a quick check I can compile everything with PNG by setting the auto_pdf to FALSE and finally when I'm ready to publish I can set it to TRUE.

It is though still not clear to me in which cases the auto_pdf is useful without the new option. Would you care to illuminate me?

P.S.: while testing I also noticed that in the "Unexpected pdf" case, the size of the plot if controlled by the regular "fig.*" options, whereas when the pdf is actually expected, these options don't apply. Maybe this is a hint if this issue appears again in the future in some other situation.

@davibicudo
Copy link
Author

A quick question regarding the update. In my case I'm using bookdown and the issue is still there, but I guess once v1.21 is deployed it will be also available for bookdown via devtools? Or am I missing something?

@github-actions
Copy link

This old thread has been automatically locked. If you think you have found something related to this, please open a new issue by following the issue guide (https://yihui.org/issue/), and link to this old issue if necessary.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Nov 10, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants