rendering a gt table with typst in R quarto

[torven-schalk]

Bug description

I'm trying to create a quarto document and render it to pdf via typst. I have source notes for my gt tables which don't accept any line break via \ or <br>. It works fine if just run in R but once rendered the line break doesn't work and it keeps the table at the width the source note occupies, no matter what I specify in cols_width()
When rendered to html the line breaks. But I can't get the line to break (and more importantly to make cols_width() work) when rendering to typst. Any help would be much appreciated.

I'm sorry if this is the wrong place to post it but I'm not sure if this is for quarto, gt, or typst to solve...

Steps to reproduce

---
title: "Untitled"
format: typst
---

```{r}
library(tidyverse)
library(gt)

head(mtcars) %>% 
  select(1:4) %>% 
  gt() %>% 
  tab_source_note(md("*Bla*. hello i'm a footnote thats<br>too long for this table.")) %>%
  cols_width(everything() ~ px(50))
```

Expected behavior

A gt table in pdf with the source note accepting a line break.

Actual behavior

No line break accepted

Your environment

RStudio 2023.12.1
R 4.4.0
Windows 11

Quarto check output

Quarto 1.6.39
[>] Checking environment information...
      Quarto cache location: C:\Users\name\AppData\Local\quarto
[>] Checking versions of quarto binary dependencies...
      Pandoc version 3.4.0: OK
      Dart Sass version 1.70.0: OK
      Deno version 1.46.3: OK
      Typst version 0.11.0: OK
[>] Checking versions of quarto dependencies......OK
[>] Checking Quarto installation......OK
      Version: 1.6.39
      Path: C:\Users\name\AppData\Local\Programs\Quarto\bin
      CodePage: 1252

[>] Checking tools....................OK
      TinyTeX: v2024.04
      Chromium: (not installed)

[>] Checking LaTeX....................OK
      Using: TinyTex
      Path: C:\Users\name\AppData\Roaming\TinyTeX\bin\windows\
      Version: 2024

[>] Checking basic markdown render....OK

[>] Checking Python 3 installation....OK
      Version: 3.12.3
      Path: C:/Users/name/AppData/Local/Programs/Python/Python312/python.exe
      Jupyter: (None)

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

[>] Checking R installation...........OK
      Version: 4.4.0
      Path: C:/Users/name/AppData/Local/Programs/R/R-4.4.0
      LibPaths:
        - C:/Users/name/projectlibrary/renv/library/windows/R-4.4/x86_64-w64-mingw32
        - C:/Users/name/AppData/Local/R/cache/R/renv/sandbox/windows/R-4.4/x86_64-w64-mingw32/716d6ec8
      knitr: 1.46
      rmarkdown: 2.27

[>] Checking Knitr engine render......OK

[cderv]

I think there are several things here.

First, using <br> is HTML, so using it in Markdown string will mean it will be lost when converting to Typst. Raw content are only meant for a specific output format.

So use markdown syntax only:

head(mtcars) %>% 
  select(1:4) %>% 
  gt() %>% 
  tab_source_note(md("*Bla*. hello i'm a footnote thats\
too long for this table.")) %>%
  cols_width(everything() ~ px(50))`

https://pandoc.org/MANUAL.html#extension-escaped_line_breaks

But this won't work for footer in typst table because of some processing we do. Any markdown styling is lost. 🤔

[cderv]

I think there is a combination of factor leading to wrong parsing here

• gt uses the qmd-base64 feature to pass some information to Quarto to be parsed. (from TABLE feature: https://quarto.org/docs/authoring/tables.html#html-tables)
• However, it seems gt is applying some markdown conversion before passing it to quarto (https://github.com/rstudio/gt/blame/31c1632ba84347e513c3fbdf0e91de5ff4bfbf4c/R/quarto.R#L33-L41). This seems not right, because then markdown seems to be converted to HTML before being encoded for quarto.
• Then there is a internal filter thing as our pipeline will first parse HTML table, and then decode the attributes
  

  quarto-cli/src/resources/filters/normalize/astpipeline.lua

  Lines 24 to 52 in 37bc223

  	return {
  	{ name = "normalize-table-merge-raw-html", filter = table_merge_raw_html() },
  	-- this filter can't be combined with others because it's top-down processing.
  	-- unfortunate.
  	{ name = "normalize-html-table-processing", filter = parse_html_tables() },
  	{ name = "normalize-combined-1", filter = combineFilters({
  	extract_latex_quartomarkdown_commands(),
  	forward_cell_subcaps(),
  	parse_extended_nodes(),
  	code_filename(),
  	normalize_fixup_data_uri_image_extension(),
  	warn_on_stray_triple_colons(),
  	})
  	},
  	{
  	name = "normalize-combine-2",
  	filter = combineFilters({
  	parse_md_in_html_rawblocks(),
  	parse_floatreftargets(),
  	parse_blockreftargets()
  	}),
  	},
  	{
  	name = "normalize-3",
  	filter = handle_subfloatreftargets(),
  	}
  	}

This means the HTML passed to quarto by gt is seen as HTML and so not applying to typst.

So something to look into in gt first IMO. @rich-iannone what do you think ?

Maybe we need to consider context = "typst" somehow, even if gt produces HTML table so that some specific handling are not done.

Anyway, I would have expected md() to be a passthrough to Quarto and not being processed in gt by markdown or commonmark. Maybe I am wrong though. Can we look at it together ?

[torven-schalk]

thanks for looking into this. Is there any way in quarto or typst templates to force an automatic linebreak or anything to force the dislay of the table with the column widths specified in gt?

[gordonwoodhull]

Funny, this works for me. What am I doing differently?

I use the <br> syntax in the example above (it would be fiddly to figure out how to escape the backslash one).

With keep-typ: true I see idiomatic Typst output

  table.footer(table.cell(colspan: 4)[#emph[Bla];. hello i’m a footnote thats \
    too long for this table.],),

gt currently outputs as HTML table, and we parse HTML raw blocks separately with html-table-processing and add them to the Pandoc AST. So as long as Pandoc is happy with the contents of the HTML table, and the output format writer supports it, it should come through.

Diffing our quarto checks, the main difference that stands out is that I am on macOS and you and @cderv are on Windows, wondering if there is platform-specific behavior creeping in.

[mcanouil]

@gordonwoodhull What's the version of gt you are using? I'm using 0.11.1 on macOS and R 4.4.2.

Input	Output
--- title: "Untitled" format: typst --- ```{r} #| include: false library(dplyr) library(gt) ``` ```{r} mtcars |> head() |> select(1:4) |> gt() |> tab_source_note( md( "*Bla*. hello i'm a footnote thats<br>too long for this table." ) ) |> cols_width(everything() ~ px(50)) ```

[mcanouil]

It seems 0.11.0 broke a number of things.
Here is with 0.10.0.

Input	Output
--- title: "Untitled" format: typst --- ```{r} #| include: false library(dplyr) library(gt) ``` ```{r} mtcars |> head() |> select(1:4) |> gt() |> tab_source_note( md( "*Bla*. hello i'm a footnote thats<br>too long for this table." ) ) |> cols_width(everything() ~ px(50)) ```

[mcanouil]

I was able to pinpoint where this breaking change happened.

rstudio/gt@3a0eec8

CC @rich-iannone

[gordonwoodhull]

Thanks @mcanouil. Yes, I was on 0.10.1 but upgrading to 0.11.1 I see the lost line break.

And I also see what @cderv is saying about the data-qmd-base64. If I remove that wrapping span I get the line break back.

Interestingly, escaping the backslash syntax does work. (whoops this was 0.11.0, with 0.11.1 the base64-encoded backslash content is converted to <br />)

[rich-iannone]

Thanks for reporting and letting me know what happened here. I'll create a fix soon for this regression (and then add some more gt/Quarto testing).