Quarto attempts to install LaTeX packages when using wkhtmltopdf as pdf engine

[HaroldDMiller]

Bug description

When using wkhtmltopdf as the pdf engine, the output pdf starts with a line reading:
\usepackage{booktabs} \usepackage{caption} \usepackage{longtable}

I tried adding these to the YAML and it didn't solve the problem:
latex-auto-mk: false
latex-auto-install: false

Steps to reproduce

No response

Expected behavior

No response

Actual behavior

No response

Your environment

No response

Quarto check output

No response

[mcanouil]

Thanks for the report.

Could you please fill in the section such as step to reproduce?
Currently it's hard to understand what's your issue.

You can share a Quarto document using the following syntax, i.e., using more backticks than you have in your document (usually four ````).

````qmd
---
title: "Reproducible Quarto Document"
format: html
---

This is a reproducible Quarto document using `format: html`.
It is written in Markdown and contains embedded R code.
When you run the code, it will produce a plot.

```{r}
plot(cars)
```

The end.
````

[HaroldDMiller]

The problem occurs when using a gt table that doesn't use the as_raw_html() option. The example below has the same table, one with that option on and the other without. The first table fails to display and the output has the LaTeX package string as the first line.

---
format:
  pdf:
    pdf-engine: wkhtmltopdf
---

```{r}
#| include: false
#| echo: false

library(tidyverse)
library(gt)

TABLE <- tribble(
  ~Column1, ~Column2,
  "A", 1,
  "B", 2
)

```

The first gt table does not display, but produces a line with LaTeX packages.

```{r}
#| include: true
#| echo: false

TABLE %>%
  gt(
  ) %>%
  tab_header(
    title = html("Standard GT Output")
  ) %>%
  cols_label(
    Column1 = html("Column 1"),
    Column2 = html("Column 2")
  ) %>%
  fmt_number(
    columns =
      c(
        Column2 
      ),
    decimals = 0
  )

```

The second gt table does display.

```{r}
#| include: true
#| echo: false
 
TABLE %>%
  gt(
  ) %>%
  tab_header(
    title = html("GT Output as Raw HTML")
  ) %>%
  cols_label(
    Column1 = html("Column 1"),
    Column2 = html("Column 2")
  ) %>%
  fmt_number(
    columns =
      c(
        Column2 
      ),
    decimals = 0
  ) %>%
  as_raw_html()

```

[mcanouil]

If you don't tell gt to output HTML for PDF which means LaTeX, how can you expect it to do so?
There are no issue here.
If you want HTML for PDF, you have to tell the third party tool you are using to do so.

[mcanouil]

I am closing this as to me it's not a bug but rather a mis-specification/usage of a third party tool.

[HaroldDMiller]

When you render a Quarto file that includes a GT table in HTML, you don't have to tell GT to output in HTML, so why would you have to modify the GT file to output HTML when you're rendering to a PDF?? If Quarto isn't using a LaTeX engine for the PDF rendering, then it's a bug when LaTeX packages are included in the output. One of the strengths of Quarto is that it allows you to render the same file to either PDF or HTML. But if you have to modify GT to output differently for different output formats, then you lose that advantage. GT isn't a "third party tool," it's a package that is maintained by Posit, as is Quarto, and GT is the best tool available for creating tables, so it would be really nice if they worked together. I was trying to use wkhtmltopdf and weasyprint to overcome the problem that LaTeX rendering of GT tables in Quarto loses the formatting created in GT, and while they do solve that problem, they require modifying the GT code (and they also lose most of the formatting for the text). So as best as I can tell, there is no way to use GT in Quarto and get well-formatted tables and text in PDFs.

[mcanouil]

gt outputs what seems to be needed:

---
format: pdf
keep-tex: true
---

```{r}
gt::gt(head(iris))
```

Look at the tex file.

If you change the engine for LaTeX, Quarto would need to know as gt, that it should output something else.

GT isn't a "third party tool,"

It is as it is not natively integrated nor embedded in Quarto.
It's a tool maintain by Posit, as such gt supports/outputs are more adapted to Quarto, but that's it.
Quarto intends to supports any R packages or Python libraries that outputs tables.

So as best as I can tell, there is no way to use GT in Quarto and get well-formatted tables and text in PDFs.
If by "well" formatted you mean with CSS and all HTML styles, but that's not really something new I'm afraid.
So if you don't want to tell gt that when you want format: pdf you actually want HTML code, there is a function built in gt to do that and it will work for other HTM based formats.

@rich-iannone might have some thought on the subject.

[baptiste]

It seems to me that there should be a smarter kind of knitr hook to tell gt to output HTML when the output format is pdf but produced by wkhtmltopdf rather than LaTeX. At the moment it looks like it's only deciding what to print based on the format

(I imagine that's a widespread issue, not just for tables)

[mcanouil]

The issue is that wkhtmltopdf is only one engine and gt is only one R package.
Meaning, to be "smart" all third party tools that generate tables would need to be aware of the pdf-engine specification or Quarto would need to be aware of what all third party tools output and "ask" them to output differently based on its knowledge of the pdf-engine specification.

FYI, the valid/supported by Pandoc engines: pdflatex, lualatex, xelatex, latexmk, tectonic, wkhtmltopdf, weasyprint, pagedjs-cli, prince, context, pdfroff, and typst.

In my opinion, it's up to third party tool or user to make sure the output is correct based on the settings the user changed.