gtsummary has been absolutely amazing for my workflow, and I would like some advice on how to switch between html and word output documents from Rmds.
In my current workflow, I tend to make large html files that are convenient for collaborators to navigate through. I can easily have dozens of gtsummary tables presented in an document. However, when it comes to collaborative writing of reports, I transition to working in Word.
My current workflow is to go through my documents, searching for every tbl_regression or tbl_merge, etc, and adding a as_flex_table() to the end of the pipe sequence. Is there a better way to do this? Should I just as_flex_table() everything from the beginning, since I know that moving to Word for any given document is likely as the project finishes?
In my dream world, there would be wrapped functions for every gtsummary function that would create a gt/gtsummary object if the output of the Rmd is html and a flextable output if the output of the Rmd is Word, but perhaps that is overkill!
There are a couple of ways to approach this that I think will fit well into your workflow.
By default, a gtsummary table is printed using gt for HTML output. If your output is Word AND the flextable package is installed, flextable will be used to print the tables. If flextable is not installed, the package will fall back to using knitr::kable() which is not as beautiful as gt and flextable. The defaults are explained in this vignette: gtsummary + R Markdown • gtsummary
You can also specify the printer for each document using the themes: theme_gtsummary_printer(print_engine=). You can add this to the top of your script, and depending on the output type, specify print_engine = "gt" or print_engine = "flextable". Specifying theme_gtsummary_printer(print_engine = "flextable") at the top of your script is equivalent to adding <gtsummary table> %>% as_flex_table() to every gtsummary table in your document.
That is SO much better than what I had been doing! Thank you for spelling this out and thanks for the wonderful documentation that I clearly need to spend more time with.