quarto-dev / quarto-cli

Open-source scientific and technical publishing system built on Pandoc.
https://quarto.org
Other
4k stars 329 forks source link

Debug/see individual steps in yaml-knitr-pandoc-lua-tex toolchain #1892

Open jjallaire opened 2 years ago

jjallaire commented 2 years ago

Discussed in https://github.com/quarto-dev/quarto-cli/discussions/1756

Originally posted by **baptiste** August 9, 2022 Is there a way to get more information on the commands that are run by quarto? Specifically, with the previous Rmarkdown workflow I could see exactly what commands were passed to pandoc, which helped a bit debug individual steps in the toolchain (is it a Yaml option passed incorrectly? Is it a pandoc issue? Is it something that knitr produced? etc.) As a specific example, I'm struggling to set the size of an image and keep the aspect ratio, for latex output. I suspect a combination of pandoc and quarto, but it's hard to tell what's happening. > `![](penguins){width=100%}` gives me > `\includegraphics[width=1\textwidth,height=\textheight]{penguins.pdf}` (and a stretched image) while > `![](penguins){width=100%,keepaspectratio}` produces > `\includegraphics{penguins.pdf}` (this is mostly for the sake of concrete illustration, I'm also interested in the general toolchain debugging question)
jjallaire commented 2 years ago

Full disclosure that the actual pandoc command is more complicated that what is shown (e.g. we implement some pandoc features like number-sections internally in our Lua filters so while number-sections: true appears in the printout we actually pass number-sections: false). That print-out is mostly informational to show the user how their metadata resolved/merged and note differences in pandoc defaults that our formats use. The actual pandoc command involves lists of filters and temporary include files (which are removed after render) so there isn't a practical way to preserve exactly the pandoc command and re-run it (as you can do e.g. for .tex).

All of that said, I have found it personally useful for debugging a number of times to show what's actually sent to pandoc so I do think a mode that prints all of this clearly (and/or writes it to a log dir) would be quite useful and something we should do sooner rather than later.