search

quarto-dev / quarto-cli

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

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

Open HaroldDMiller opened 1 year ago

HaroldDMiller commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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.

#| 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.

#| 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 commented 1 year ago

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 commented 1 year ago

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

HaroldDMiller commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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.

HaroldDMiller commented 1 year ago

For me, the real issue is getting gt to work with Quarto via the standard LaTeX engines in order to produce nicely formatted tables. The other table generation packages, such as kableextra, are vastly inferior to gt in terms of overall capabilities, but they are compatible with Quarto pdfs. gt and Quarto work beautifully together for html output and produce far superior results to other packages, but they don't work together for pdf output. I really have no desire to use wkhtmltopdf (particularly since it's no longer being maintained) because everything else I do with markdown & r work well in Quarto for both html and pdf. The only gap is producing tables in pdf. The solution I'm currently using is to output the gt tables as a png file and then display the png file as an image. This preserves all of the formatting added by gt, but the scaling of the image has to be done manually in order to have some semblance of consistency in font size, but it still generally looks bad if there are multiple tables of different widths. I don't know whether the best solution is to change gt or Quarto or both, but it seems to me to be important functionality for Quarto to have. I found what I reported as a bug when I was trying to find alternative solutions, but I see the real goal as enabling Quarto to use gt to produce pdfs.

mcanouil commented 1 year ago

Quarto does not control what gt outputs (or any R packages/Python module for that matter). For enhance LaTeX support in gt, I suggest to take a look and ask on the relevant repository: https://github.com/rstudio/gt/issues.

EDIT: It appears you already open the same discussion on gt repository for some reasons.

cderv commented 1 year ago

Regarding this topic of using some pdf-engine for Pandoc that are not LaTeX engine, but PDF printer, this is still to be supported by Quarto correctly See

and another slightly related issue illustrating that there is no specific support for wkhtmltopdf (https://github.com/quarto-dev/quarto-cli/issues/3243)

I know the reference page currently state this is a possible value, but I believe this is a "copy" of the Pandoc's MANUAL reference for this option: https://pandoc.org/MANUAL.html#option--pdf-engine

Currently, pdf-engine under pdf really means PDF engine for the PDF format as we document under https://quarto.org/docs/output-formats/pdf-engine.html#alternate-pdf-engines

It does not mean PDF engine for HTML format (to output a PDF version). This is indeed troubling for now, but really that is the main issue here : using wkhtmltopdf as the pdf engine is not supported in Quarto as of now

A bit more about "unsupported"

To be clear, there is not specific support for pdf-engine: wkhtmltopdf in Quarto code base. Meaning that when providing 

format:
  pdf:
    pdf-engine: wkhtmltopdf

Quarto will do everything expected for a PDF output (--to pdf) but pdf-engine is then pass to Pandoc and this means that --to pdf will be ignored. Pandoc will do a HTML conversion and then prints to PDF using the tool. No specific Quarto support as opened #222 shows.

I believe if it was supported it would be something like IMO

format:
  html:
    pdf-engine: wkhtmltopdf

Alternative for PDF with LaTeX

To produce PDF without LaTeX, so other supported way is the new format Typst currently in pre-release (https://quarto.org/docs/prerelease/1.4/typst.html) which uses a new tool: https://typst.app/

baptiste commented 1 year ago

So, if I try to summarise the above, there are different things being discussed here:

  1. gt tables don't have a full-featured LaTeX output (yet) (personally, I'd look into tabularray to support more of the styling features, thought it's a bit bleeding-edge and slow)
  2. converting gt tables HTML output to something that can be included in LaTeX isn't straight-forward
  3. alternative pdf routes such as wkhtmltopdf aren't supported by the quarto toolchain (the pandoc part takes care of it, but quarto does not support these as proper pdf-engines)
  4. getting gt to produce HTML rather than LaTeX output isn't tied to (unsupported) engines such as wkhtmltopdf
  5. typst won't like gt's HTML any better (at present)

I think the issue title corresponds to 4) and possibly 2), but since wkhtmltopdf isn't a supported engine, it is not really an actionable issue in itself (but rather a part of #222, i.e. 3)).

1) is a gt issue, already well-documented.

That leaves 2) and 5) as possible actionable improvements, in my view: there could be an option – probably best defined as a knitr option like gt.html_to_pdf = TRUE – to trigger the automatic conversion of gt tables into a (vector) image that is compatible with LaTeX and Typst, and better than a screenshot. wkhtmltopdf seems to be deprecated, but perhaps weasyprint could be used for this purpose (rather than converting a whole document, it would only convert the HTML table from gt – something like this example).

HaroldDMiller commented 1 year ago

Thank you for trying to help with this. Yes, solving 1) would solve the problem. The alternative that I was hoping to find is this: 6) a way for Quarto (or some combination of Quarto & knitr) to take the standard output of gt (which is an r object not html per se, unless you tell it to output raw html), and display it with the css formatting that gt creates intact. Currently I am solving this manually by adding a gtsave command after each set of gt table code in order to create a .png file for that table, then displaying that .png as a figure in Quarto. However, in order to do that, the gt output first has to be put in an r object in order to save it, and that in turn means that a couple of additional lines have to be added to display the r object directly when rendering to html but not when rendering to pdf, and vice versa. Since this is exactly the same process for each table, it would be nice if Quarto could do it automatically. All of the rest of the document formatting for the pdf is done in LaTeX, so all of that is lost if I try to create a pdf through the html-pdf packages.
Quarto does an awful lot to enable use of a lot of other third-party software packages as part of Quarto documents, so I don't see why doing that for gt would be any different.

baptiste commented 1 year ago

I think it should be possible to define a knitr hook to automate the process of turning a gt into an image and include it in the output. I'm not too familiar with the gt print methods etc., but it seems worth a try.

---
title: "Untitled"
format: 
  pdf:
    latex-tinytex: false
    keep-md: true
---

```{r}
library(knitr)
library(glue)
library(gt)
if(!require(webshot2)) warning("you'll need this")

knit_print.gt_tbl = function(x, ...) {
  f <- glue("{opts_current$get('label')}-gt_tbl.png")
  x |> gtsave(filename=f)
  knitr::asis_output(glue("![]({f})"))
}

registerS3method(
  "knit_print", "gt_tbl", knit_print.gt_tbl,
  envir = asNamespace("knitr")
)
head(iris) |> gt()


![Screenshot 2023-07-04 at 17 20 38](https://github.com/quarto-dev/quarto-cli/assets/18970/18dc78bb-1dca-4595-931c-d5a272b4a76d)

One would want to pass options for the size etc., and personally I would prefer to try using weasyprint to get a vector graphic for the table rather than a screenshot, but the process of automation seems doable.
cderv commented 1 year ago

, there are different things being discussed here:

Thanks @baptiste for this ! Indeed there are several things mixed up in this thread. I'll also try to add comment to your great summary

It will be a very long reply below because there are a lot of different topics here. Related, but mixed together.

  1. gt tables don't have a full-featured LaTeX output (yet)

gt has support for LaTeX output through the as_latex() function (https://gt.rstudio.com/reference/as_latex.html) If some features are missing compare to what is possible with HTML tables, then it should be dealt with in gt. @rich-iannone will be more than happy to improve the package. I believe the missing features should be reported to gt directly, so thanks for https://github.com/rstudio/gt/issues/1363

  1. converting gt tables HTML output to something that can be included in LaTeX isn't straight-forward

The way to include a gt table into a LaTeX document for PDF is with as_latex() described above. a gt() object should be printed using this function when in a format: pdf document (This is what the knit_print() methid is doing (source))

  1. alternative pdf routes such as wkhtmltopdf aren't supported by the quarto toolchain (the pandoc part takes care of it, but quarto does not support these as proper pdf-engines)

Yes for know, this is the case. It could work but it is not properly implemented, so I believe there would be stuff not working, and it is not straighforward as we see from this discussion. Mainly thing is that format: pdf will trigger everything in Quarto codebase, and then in tools like knitr to expect a LaTeX output, not a HTML to be printed.

  1. getting gt to produce HTML rather than LaTeX output isn't tied to (unsupported) engines such as wkhtmltopdf

Usually Quarto is passing the information about output format to target, and knitr will pass it to other packages in R. However, for now, even in rmarkdown the pdf-engine value is not something that will have impact on the other tooling. Only the targeted format. Here we pass format: pdf to it targets LaTeX. As I said above I believe supported clearly wkhtmltopdf would be something like 

format: 
    html: 
        pdf-engine: wkhtmltopdf

as we want HTML format, but with a output-file with pdf extension.

  1. typst won't like gt's HTML any better (at present)

You are completely right. Currently Typst is a specific outputs and it requires Pandoc to write tables to it. This means gt output HTML tables => Quarto parse it in Pandoc => Pandoc writes it to the outputs. Obviously, this has the side effect of having specific gt feature for styling and layout, not supported by Pandoc's table to be lost.

probably best defined as a knitr option like gt.html_to_pdf = TRUE – to trigger the automatic conversion of gt tables into a (vector) image that is compatible with LaTeX and Typst, and better than a screenshot.

Really as_latex() is the way to output LaTeX from a gt() object. This is what should be improved if it is not rendering as it should.

Example qmd document to PDF with gt as LaTeX table ````markdown --- title: test format: pdf --- ```{r} library(gt) tab_latex <- gtcars |> dplyr::select(mfr, model, msrp) |> dplyr::slice(1:5) |> gt() |> tab_header( title = md("Data listing from **gtcars**"), subtitle = md("`gtcars` is an R dataset") ) ``` It will be converted to LaTeX code ```{r} res <- tab_latex |> as_latex() cat(unclass(res[1])) ``` which will render like this ```{r} tab_latex ``` ```` ![image](https://github.com/quarto-dev/quarto-cli/assets/6791940/25b93185-d2d3-4f07-90b5-d2735f45709b)

@HaroldDMiller and @baptiste I believe the real question here is about the Rendered Output for LaTeX with gt itself. Independant of Quarto. gt can be used with R Markdown the same way in pdf_document and @rich-iannone spent some time to make the as_latex() feature possible for having output tables to be as similar as they could. Probably more can be done.

Though nothing exists yet (AFAIK) to transform CSS to LaTeX, so indeed customizing a gt table with some HTML specific styling won't be something translated to LaTeX exactly the same.

FWIW this logic is what Quarto does for a lot of feature:

R packages are doing this too in gt, knitr::kable(), flextable and others...

I think it should be possible to define a knitr hook to automate the process of turning a gt into an image and include it in the output. I'm not too familiar with the gt print methods etc., but it seems worth a try.

@baptiste about this it indeed works correctly. Though you are overriding the internal knit_print method already defined in gt. (the one I mentioned above and using as_latex() already.

All of the rest of the document formatting for the pdf is done in LaTeX, so all of that is lost if I try to create a pdf through the html-pdf packages.

@HaroldDMiller I understand the aim is to produce PDF from a HTML document. For now, it needs to be a 2 steps process.

Example with pagedjs-cli (Currently a NPM package: https://www.npmjs.com/package/pagedjs-cli) 

quarto render test.qmd --to html
pagedjs-cli test.html -o test.pdf

This tool will server your HTML document, insert what is need (paged.js library) and do a "chrome print" to output to PDF. The style will be kept

HTML version PDF Version
![image](https://github.com/quarto-dev/quarto-cli/assets/6791940/aec0fe03-9153-4146-b049-0e81174417ad) ![image](https://github.com/quarto-dev/quarto-cli/assets/6791940/a028b62a-670d-4a6c-9df3-e989512abf29)

Maybe we can think of a quarto print method in the future for such integration like Pandoc is doing, but more tied to Quarto features.

Hope this details help gets a broad overview of the situation. I'll forward all this to @rich-iannone so that he can answer and discuss in https://github.com/rstudio/gt/issues/1363 regarding the gt to LaTeX rendering.

HaroldDMiller commented 1 year ago

Thank you for spending so much time trying to help resolve this!. However, I apparently haven't yet clearly conveyed the goal I'm trying to achieve and the desirability of doing so, nor have I been able to convey the lack of parallelism I see between the way Quarto processes gt output compared to other components of a qmd document. My goal is to use the same .qmd file and be able to render it to either pdf or html (which is what Quarto says it wants to do), not to have a file specifically designed to produce only Latex. If I specify Latex output from gt, then I can't use it for html. If I have the file set up only for html and convert the html to pdf, I lose all of the functionality of Latex for pdfs.

This problem exists with gt for tables, but not with ggplot for graphs. If I create a plot in ggplot, it will render exactly the same in html and pdf, without making any changes to the ggplot code. But if I create a table in gt, it will not render the same in pdf as it does in html. (See example below.) If I use gtsave to save the gt output as a png file and then display the image of the table rather than the actual gt object, the table loses the responsive features of an html table in html, and different size tables appear to have different font sizes in the pdf because webshot2 produces all of the images at full page width.

I tried to raise this issue as a feature request in Quarto, but it was closed for reasons I don't understand or agree with. The only reason this is showing up here is that I found a problem in Quarto when I was exploring whether a different pdf engine would work differently. But I really don't want to use a different pdf engine!! I honestly don't understand whether the best way to fix this is via gt or Quarto or knitr or some combination, but the functionality is needed.

Here's an MRE that includes both a ggplot graph and a gt table based on the same data. If you render it in both html and pdf, the graph looks identical, but the gt table does not:

---
knitr:
  opts_chunk: 
    echo: false
    include: true
---

```{r}
#| include: false
library(tidyverse)
library(gt)

DATA <- tribble(
  ~X, ~Y,
  10, 15,
  20, 20,
  30, 15
)

This is text.


DATA %>%
ggplot() +
geom_col(mapping = aes(x = X, y = Y, fill = X)) +
theme_classic() +
theme(axis.text.x = element_text(color = "red", 
                                   size = 14),
        axis.title.x = element_text(color = "green", 
                                    size = 18),
        axis.text.y = element_text(color = "orange", 
                                   size = 14),
        axis.title.y = element_text(color = "black", 
                                    size = 18)
                                    )


DATA %>%
 gt() %>%
 cols_label(
  X = html("Column 1"),
  Y = html("Column 2")
  ) %>%
 tab_style(style = list(cell_text(align = "center",
                                  weight = "bold",
                                  color = "red"),
                        cell_borders(sides = c("all"),
                                     weight = px(3))),
           locations = cells_column_labels(columns = everything())) %>%
 tab_style(style = list(cell_text(align = "center",
                                  color = "blue")),
           locations = cells_body(columns = everything())) %>%
 tab_style(style = list(cell_borders(sides = c("all"),
                                     weight = px(2))),
           locations = cells_body(columns = everything())) %>%
 opt_table_outline(style = "solid", width = px(3), color = "black")
cderv commented 1 year ago

Thanks for taking the time to add precision to your thoughts. I think things got sidetracked by the number to topic mixed up.

My goal is to use the same .qmd file and be able to render it to either pdf or html

We agree on the goal. For all feature, we are trying to do the best we can for that. We try to give similar outputs for similar feature in the limit of what is possible.

For example if you style a format: html with a Quarto theme, and then you try rendering to PDF, all your styling will not apply. This is because it is format specific - CSS does not translate to LaTeX styling. The way to style LaTeX and HTML are different. This limitation applies also to third party tooling too.

For tables, we try already to do something as similar as possible for the outputs format by parsing any Markdown and HTML table the same. This means any tool that will produce HTML table will be read as Table element and not seen as HTML code (unless this feature is opt out by the third party).

So you are right that this is the aim and everything is done at best for this, it keeps being improved.

not to have a file specifically designed to produce only Latex. If I specify Latex output from gt, then I can't use it for html. If I have the file set up only for html and convert the html to pdf, I lose all of the functionality of Latex for pdfs.

gt already offers this as I explained in my long answer above (https://github.com/quarto-dev/quarto-cli/issues/6084#issuecomment-1619900322). If there is a gt() object found in a quarto document by knitr, then gt will output HTML if format: html or will output LaTeX if format: pdf. The user does not have to specify as_latex() or as_raw_html()

When you create your gt object 

DATA %>%
 gt() %>%
 cols_label(
  X = html("Column 1"),
  Y = html("Column 2")
  ) %>%
 tab_style(style = list(cell_text(align = "center",
                                  weight = "bold",
                                  color = "red"),
                        cell_borders(sides = c("all"),
                                     weight = px(3))),
           locations = cells_column_labels(columns = everything())) %>%
 tab_style(style = list(cell_text(align = "center",
                                  color = "blue")),
           locations = cells_body(columns = everything())) %>%
 tab_style(style = list(cell_borders(sides = c("all"),
                                     weight = px(2))),
           locations = cells_body(columns = everything())) %>%
 opt_table_outline(style = "solid", width = px(3), color = "black")

It is not yet transformed - it is an R object.

The output you get from gt is a matter of support in gt directly, not Quarto.

LaTeX support in gt is quite recent, and it needs to be improved. Supporting color cells is one of the missing feature. That is why you are for now loosing the color. Because it is not the same way to style HTML and LaTeX, so support needs to be done in both type of output. (and any other type targeted like RTF or DOCX, or others)

This is a gt improvement. And this problem will be the same with any third party - Quarto allows to render in different outputs, the third party tools needs to adapt to make thinks easy for the users. Here, Quarto does not control what gt() %>% as_latex() is outputing to translated col_text(..., color = "red")

I hope this makes things clearer on that.

This problem exists with gt for tables, but not with ggplot for graphs. If I create a plot in ggplot, it will render exactly the same in html and pdf, without making any changes to the ggplot code.

plots are save to a file and then included in the format using the correct HTML or LaTeX code. knitr will do that for you to format correctly the file insertion as image in your output.

For table, you don't want images, so it has to works differently. You can do image of table with gt_save()- that way it will be included the same in both your doc.

gt could have an option for knit_print.gt_tbl() to always to an image and not output LaTeX if you prefer that. For format: pdf, it should just output a PDF file if you want better vectorize output. I'll try to build an example to show you how this can be done if you are looking for this.

I tried to raise this issue as a feature request in Quarto, but it was closed for reasons I don't understand or agree with.

Because we understand that the underlying issue is better output for LaTeX of the R gt() object, and this is a gt improvement that the gt Maintainer will look into as part of

Quarto can't really change what gt() is doing. It is the same with any other third party tools like Pandas in python, or other R packages like flextable or kableExtra.

Sometimes we tweak the output a bit to bring support to specific Quarto features (like cross ref) but that quite scoped.

If some adaptation are required in Quarto to provide better support in gt for LaTeX output then we'll do that here too.

I honestly don't understand whether the best way to fix this is via gt or Quarto or knitr or some combination, but the functionality is needed.

Hope this is clear now to you that we are concerned about that, and it will be looked at by @rich-iannone and the rest of the team at the gt level.

Here's an MRE that includes both a ggplot graph and a gt table based on the same data. If you render it in both html and pdf, the graph looks identical, but the gt table does not:

Thanks for the example.

The graph is identical because it is a plot saved to file by R, and the file is included in each type of output using HTML syntax or LaTeX syntax.

The tables looks different because in HTML it will be created using HTML code and in PDF it will be created using LaTeX code. And unfortunately part of the current limitation in gt is that some feature (like cell color) are not (yet) supported for LaTeX output.

Please do tell me if anything is not yet clear enough. Rest assured that we are aware of the limitation and on this matter @rich-iannone which is working on gt works also closely with the Quarto team.

HaroldDMiller commented 1 year ago

This is extremely helpful; thank you for the very clear and detailed information. Quarto is a fantastic package, which is why I would like to see it be able to do tables as well as it does everything else. With all of the steps it goes through to do its magic, it's hard for a mere user like me to know the details of which step is doing what and which needs to change. I have a lot of LaTeX code included in the YAML for my documents to make the pdfs come out looking as good as the html version, so I really want to have gt work well via LaTeX, and I suspect a lot of other people would find that valuable, too. So thank you to you, @rich-iannone, and anyone else who can make this happen!