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

include_graphics fails with '~' home directory shorthand #1411

Closed
RoyalTS opened this issue Jun 23, 2017 · 7 comments
Closed

include_graphics fails with '~' home directory shorthand #1411

RoyalTS opened this issue Jun 23, 2017 · 7 comments
Milestone

Comments

@RoyalTS
Copy link

RoyalTS commented Jun 23, 2017

include_graphics apparently fails on Mac when I specify a path using the ~ shorthand for the user home directory.

```{r}
knitr::include_graphics('~/myProject/out/figures/2017-06-23/sample_size_all.pdf')
```

gives

[pandoc warning] Could not find image `~/myProject/out/figures/2017-06-23/sample_size_all.pdf', skipping...

upon knitting. The following works, in contrast:

```{r}
knitr::include_graphics('/Users/myUsername/myProject/out/figures/2017-06-23/sample_size_all.pdf')
```
@yihui
Copy link
Owner

yihui commented Jun 23, 2017

Absolute paths like this is almost always a very bad idea. Please use relative paths instead for the sake of portability.

@RoyalTS
Copy link
Author

RoyalTS commented Jun 23, 2017

I am well aware that it's usually a good idea to use paths relative to the location of the document. In this case, however, precisely for reasons of portability I've specified all paths relative to project root using the here package, which spits out absolute paths. The above is just a demonstration that some absolute paths don't seem to work for include_graphics.

@yihui
Copy link
Owner

yihui commented Jun 23, 2017

I guess it is not the responsibility of knitr::include_graphics() to process the path. This function takes whatever paths you pass to it. It is Pandoc that failed to recognize ~. If this issue has to be fixed, I'd recommend the here package to do either of the following things:

  • normalizePath() or path.expand();

  • or return a relative path (at least provide an option to return a relative path).

I have my reserved opinions about here. I see its point, but I don't think this nasty problem of file paths really has a perfect solution.

@jzadra
Copy link

jzadra commented Jun 24, 2017

THe odd thing is that paths with '~' work for ioslides, but not html/doc documents, and both use pandoc. Couldn't include_graphics() just expand the path itself to avoid this error?

@yihui
Copy link
Owner

yihui commented Jun 25, 2017

It could. It is just that I prefer fixing the disease instead of the symptoms. In this case, it is not the fault of include_graphics(). Either the user or the here package could do path.expand(). If I do it in include_graphics(), I have no idea whether it is going to have other undesired effects.

ioslides is different with all other output formats. It is based on a custom Lua writer. That is probably why Pandoc wouldn't complain about the path.

@jzadra
Copy link

jzadra commented Jun 26, 2017

Gotcha, thanks for the response and for the awesome package!

@yihui yihui added this to the v1.17 milestone Jul 22, 2017
@yihui yihui closed this as completed Jul 22, 2017
@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

3 participants