render --to pdf and render --to docx has image path problems while render --to html works

[ati-ozgur]

Bug description

I have problem rendering pdf files.

My code is public github repo: https://github.com/ati-ozgur/course-database

I created following github action which render to html works but render to pdf gives an error.

https://github.com/ati-ozgur/course-database/actions/runs/11297869117

Steps to reproduce

No response

Expected behavior

No response

Actual behavior

No response

Your environment

No response

Quarto check output

Output from github action

Run quarto check
Quarto 1.5.57

[✓] Checking versions of quarto binary dependencies...
Pandoc version 3.2.0: OK
Dart Sass version 1.70.0: OK
Deno version 1.41.0: OK
Typst version 0.11.0: OK

[✓] Checking versions of quarto dependencies......OK

[✓] Checking Quarto installation......OK
Version: 1.5.57
Path: /opt/quarto/bin

(|) Checking tools....................
[✓] Checking tools....................OK
TinyTeX: v2024.10
Chromium: (not installed)

(|) Checking LaTeX....................
[✓] Checking LaTeX....................OK
Using: TinyTex
Path: /home/runner/.TinyTeX/bin/x86_64-linux
Version: 2024

(|) Checking basic markdown render....
[✓] Checking basic markdown render....OK

[✓] Checking Python 3 installation....OK
Version: 3.10.12
Path: /usr/bin/python3
Jupyter: (None)

  Jupyter is not available in this Python installation.
  Install with python3 -m pip install jupyter

(|) Checking R installation...........
[✓] Checking R installation...........OK
Version: 4.4.1
Path: /usr/lib/R
LibPaths:
- /usr/local/lib/R/site-library
- /usr/lib/R/site-library
- /usr/lib/R/library
knitr: (None)
rmarkdown: (None)

  The knitr package is not available in this R installation.
  Install with install.packages("knitr")
  The rmarkdown package is not available in this R installation.
  Install with install.packages("rmarkdown")

[mcanouil]

Thanks for the report.
Unfortunately, we do not have the time to debug your big project in order to figure out what is wrong, that is also why we asked for a small reproducible example in the first place.

Please do provide such small reproducible example by stripping out small pieces at a time of your project until you are able to have a small example.
In the process, you'll likely figure out what's wrong and it might be an issue on your end.

Also "I have problem rendering pdf files" does not help much.
A clear depiction of the problem and where it occurs is needed to get help here and everywhere else.

[ati-ozgur]

Please. You only need to run two commands.

git clone
quarto render --to pdf.

It is a reproducible example.
This is the second time your team is ignoring my bug reports.
It seems that you are deleting this type of bug reports since I could not find my old bug report.

I spend 1 hour for creation of github action to show reproducible example.
I do not believe that you will work on my small example if I gave it to you.
Shade.

[tarleb]

Hi! First of all, thanks for taking the time to report this, and for providing an example. The community input is an integral part to making Quarto better, so it is much appreciated.

One point where I ask for your understanding is that we cannot just run those two commands, primarily for security reasons. Quarto documents can execute code, and running a project without checking the sources is a serious security risk. A big project would require a lot of time to review, which is time that would better be invested in fixing the bug.

That's why we ask for your help to narrow the problem down. You are the expert for your project, and will be able to generate a smaller example so much more efficiently than any Quarto dev could.

We'll be happy to help, but we need your help to do so.

[cscheid]

(For context, I am currently the lead developer on Quarto, and the person ultimately responsible for these forums) I will expand some more.

This is the second time your team is ignoring my bug reports.

We have not ignored your bug reports. For the reasons that both Albert and Mickael have mentioned, we cannot help you unless you provide a small reproducible example. Simply the latter is not enough. In addition to the security implications that Albert mentioned:

1. we have limited time to offer support, and you provided a 46-document repository. That's not practical for us to handle
2. it is just good debugging practice, on your own, to reduce unexpected behaviors to a small example - I believe you know that already, but it's especially true when you need to communicate with other people.

It seems that you are deleting this type of bug reports since I could not find my old bug report.

@ati-ozgur, please refrain from making serious unfounded accusations: that's a violation of our code of conduct. Specifically, this response of yours is unacceptable:

No one in this repository deletes bug reports - your message is implying unethical behavior, and that's problematic in itself. In addition, I promise you that this simply doesn't happen. I can give you two reasons: first, I trust Mickael (and the other member of the team) to not do it. Second, Mickael specifically doesn't have repository permissions to delete issues.

Please do not do this.

If you wish to continue participating in this forum, you have to be willing and able to communicate in a way that respects our code of conduct.

[ati-ozgur]

I am sorry for deleting the issue comment.
I have found my previous issues.
That is my mistake.
I am again sorry.

The problem is that this issue is not so easy to reproduce.
It needs a lot of files to be included in the project.
I spent 2 hours for trying to reproduce it but with small amount of included files, images works.

Please see my debugging issue.
#11043

I would like to debug my problem myself.

Another issue about the security.
I added an issue about it.
If security is an issue than a flag should be added to quarto for disallowing executable code for content only documents.
no executable code or content only documents flag #11050
#11050

[mcanouil]

See #11050 (comment)

[mcanouil]

Note that you have the log at https://github.com/ati-ozgur/course-database/actions/runs/11297869117
It clearly states an issue with course-contents/images/database-models.png, why don't you remove everything unrelated to that in your projects, i.e., remove everything not using this image either directly or via the include/embed shortcode?

[ati-ozgur]

That file exists and I could see it in html output.
Anyway

Here is the small repo which shows the problem.

https://github.com/ati-ozgur/quarto-bugs/tree/image-bug

This is github workflow that shows the error.

https://github.com/ati-ozgur/quarto-bugs/actions/runs/11315879262/job/31467574491

Error only exists when you use profiles, that is two _quarto*.yml file.
Also, you need to have 2 includes at least.

[cderv]

Thanks for the reproducible example. Greatly appreciated !

I believe the issue is because of the image path used

![ToadEasyConnect](./images/ToadEasyConnect.png)

when the .md is included, the path is not transformed, and the resulting content after inclusion will be this path

course-contents/./images/ToadEasyConnect.png

which latex does not like at all.

So it seems related to path transformation in a specific scenario... 🤔 I'll try to look into this closer.

[mcanouil]

When using include/embed shortcode, it is best to use project root relative paths using a starting / as it ensures that the path is correct no matter where the path is "called".

[ati-ozgur]

for me:

![ToadEasyConnect](course-contents/images/ToadEasyConnect.png)

pdf error
html error

![ToadEasyConnect](/course-contents/images/ToadEasyConnect.png)

pdf error
html works

![ToadEasyConnect](../course-contents/images/ToadEasyConnect.png)

pdf error
html works

![ToadEasyConnect](./images/ToadEasyConnect.png)


pdf error
html works

Since I am using execute-dir project as below:

project:
  type: book
  execute-dir: "project"

Image source as course-contents/images/ToadEasyConnect.png should work.

The problem with "starting /", in unix-based-systems, it is the start of absolute path.

/home/atilla/...

But if it is in the documentation, it should be acceptable too.
But, be aware that, it would be a surprise for most unix/linux users.

[cderv]

When using include/embed shortcode, it is best to use project root relative paths using a starting / as it ensures that the path is correct no matter where the path is "called".

Thanks Mickael. if you try out, the problem is deeper than that. The project root for the PDF rendering seems different that the HTML rendering, and this messes up a lot of things.

I wonder if this could be linked to change in rendering order

• Quarto does not preserve the render order mentioned in _quarto.yaml #10714

With Quarto 1.4, render order is

[1/3] index.qmd
[2/3] course-contents\database-playground-en.md
[3/3] course-contents\database-connections-en.qmd

and quarto to pdf rendering happens through a index.tex in root folder as we expect being same folder as _quarto.yml.

In this context doing ![ToadEasyConnect](/course-contents/images/ToadEasyConnect.png) works, same as relative version without leading ./: ![ToadEasyConnect](images/ToadEasyConnect.png)

However, with Quarto 1.5 and later rendering order for such project with subfolder is

[1/3] course-contents\database-playground-en.md
[2/3] index.qmd
[3/3] course-contents\database-connections-en.qmd

and this is bad because now Quarto render to pdf happens through course-contents/database-playground-en.tex which means that the tex rendering is done in a subfolder of the project. This is clearly wrong !

So right now, rendering your project with Quarto 1.4 will work.

Workaround the current bug would be using

![ToadEasyConnect](/images/ToadEasyConnect.png)

but this is clearly wrong because root ( which leading / is about) should not be course-contents/.

This is a bad regression to me, possible solves with #10714