gtcars |>
dplyr::select(mfr, model, year, hp, msrp) |>
dplyr::slice_head(n = 3) |>
gt() |>
fmt_currency(columns = msrp, decimals = 0) |>
as_raw_html()| mfr | model | year | hp | msrp |
|---|---|---|---|---|
12 Output formats
Tables created with gt are presentation-ready, but where they’re presented matters. A table destined for a web page has different constraints and capabilities than one heading into a PDF report or Word document. The gt package accommodates this diversity by supporting multiple output formats, each with its own rendering function and characteristics.
This chapter explores the five primary output formats gt supports: HTML (for web and interactive documents), LaTeX (for PDF generation), RTF (for rich text documents), Word (for Microsoft Word documents), and PNG images (for static graphics). We’ll examine how to generate each format, understand their respective strengths and limitations, and learn when to choose one over another.
12.1 HTML
HTML is gt’s native format and receives the fullest feature support. When you display a gt table in an R console, RStudio viewer, or Quarto/R Markdown HTML document, you’re seeing the HTML output.
12.1.1 Generating HTML output
The as_raw_html() function converts a gt table to an HTML string:
This returns a character string containing complete HTML markup. You can write this to a file, embed it in a larger HTML document, or pass it to other tools that consume HTML.
For saving directly to a file, use gtsave():
gtcars |>
dplyr::select(mfr, model, year, hp, msrp) |>
dplyr::slice_head(n = 5) |>
gt() |>
fmt_currency(columns = msrp, decimals = 0) |>
tab_header(title = "High-Performance Cars") |>
gtsave("cars_table.html")The resulting HTML file is self-contained and can be opened directly in any web browser.
12.1.2 Use cases
HTML output is great in these scenarios:
- web publishing: blogs, websites, dashboards, and web applications
- interactive reports: Quarto/R Markdown documents rendered to HTML
- email newsletters: HTML emails with embedded tables
- documentation: package documentation websites (pkgdown)
- Shiny applications: dynamic tables in interactive web apps
12.1.3 Advantages
HTML format provides several distinct benefits:
Every gt feature works in HTML output. Colors, fonts, borders, images, nanoplots, complex formatting, and interactive elements all render correctly. This complete feature support makes HTML the most versatile output format.
CSS styling gives precise control over every visual aspect. The tab_style() and tab_options() functions leverage CSS properties, enabling sophisticated designs. Tables can adapt to different screen sizes through CSS. While gt doesn’t provide automatic responsive behavior, the HTML output structure allows custom responsive styling.
HTML tables can contain images, icons, formatted text with HTML tags, and even embedded SVG graphics for nanoplots. This embedded content capability makes HTML tables rich and expressive.
HTML supports ARIA attributes and semantic markup, making tables more accessible to screen readers and assistive technologies. Hover effects, tooltips, and other interactive features work naturally in HTML.
12.1.4 Limitations
Despite its strengths, HTML has constraints:
Viewing requires a web browser or HTML renderer. This isn’t always available in print-first workflows. While HTML can be printed, the results often don’t match dedicated print formats like PDF. Page breaks, margins, and print-specific styling require additional effort.
Self-contained HTML files embed all styling and can become large, especially with many tables or embedded images. Some email clients or document systems strip CSS or limit HTML capabilities, potentially breaking table layouts.
12.1.5 Best practices
To maximize HTML output quality:
Different browsers may render CSS slightly differently. Test in major browsers (Chrome, Firefox, Safari) when wide distribution is expected. If embedding many tables or images, consider external CSS files to reduce duplication.
The opt_*() family of functions can enhance HTML structure for better accessibility. If the HTML will be printed, test print output and adjust styling as needed. Consider using @media print CSS rules for print-specific adjustments.
12.2 LaTeX
LaTeX is the standard for academic and technical document preparation, particularly for PDF generation. gt supports LaTeX output, enabling tables to be included in articles, books, reports, and presentations created with LaTeX or R Markdown/Quarto documents that render to PDF.
12.2.1 Generating LaTeX output
The as_latex() function converts a gt table to LaTeX code:
exibble |>
dplyr::select(num, char, currency) |>
dplyr::slice_head(n = 4) |>
gt() |>
fmt_number(columns = num, decimals = 1) |>
fmt_currency(columns = currency) |>
as_latex()This produces LaTeX table code that can be copied into a .tex document or included in R Markdown/Quarto documents with output: pdf_document.
When using R Markdown or Quarto with PDF output, gt tables automatically render as LaTeX without explicitly calling as_latex().
12.2.2 Use cases
LaTeX output suits these contexts:
- academic papers: journal articles, conference proceedings, dissertations
- technical reports: research reports, white papers, technical documentation
- books: Academic texts, technical manuals
- presentations: slides with tables
- print-quality PDFs: any scenario requiring precise typographic control
12.2.3 Advantages
LaTeX brings several benefits for table presentation. It is really good at producing publication-quality output with precise positioning, professional typography, and consistent spacing. Since LaTeX is designed for mathematical typesetting, tables containing equations integrate seamlessly with surrounding mathematical content.
LaTeX’s cross-referencing system allows tables to be numbered, labeled, and cited throughout a document. Many academic publishers require or prefer LaTeX submission, making LaTeX tables essential for scholarly communication. LaTeX-generated PDFs are stable, widely compatible, and suitable for archival purposes.
12.2.4 Limitations
LaTeX output faces several constraints. Not all gt features translate to LaTeX. Complex styling, images, web fonts, and nanoplots may not render or may render with reduced fidelity. LaTeX code must be compiled to produce viewable output. This requires a LaTeX distribution (TeX Live, MiKTeX) and can fail if required packages are missing.
Understanding LaTeX table output and troubleshooting rendering issues requires LaTeX knowledge. LaTeX produces static output. Hover effects, tooltips, and other interactive elements don’t work.
12.2.5 Best practices
For optimal LaTeX output always compile LaTeX output to verify it works correctly. Some gt features may produce LaTeX code that requires additional packages. Use simpler styles for LaTeX output. Avoid complex CSS-based styling that won’t translate well.
If sharing LaTeX code, document required packages so others can compile it successfully. LaTeX tables benefit from proper captions created with tab_header(), which translate to LaTeX \caption{} commands.
Very wide tables may need special handling in LaTeX (landscape orientation, font size reduction). Plan table dimensions accordingly.
12.3 RTF
Rich Text Format (RTF) is a document format developed by Microsoft that most word processors can read and write. gt can generate RTF output, providing a path to word processing applications that may not support HTML or direct R table imports.
12.3.1 Generating RTF output
The as_rtf() function converts a gt table to RTF code:
towny |>
dplyr::select(name, population_2021, density_2021) |>
dplyr::slice_head(n = 4) |>
gt() |>
fmt_integer(columns = population_2021) |>
fmt_number(columns = density_2021, decimals = 0) |>
cols_label(
name = "Municipality",
population_2021 = "Population",
density_2021 = "Density"
) |>
as_rtf()!!!!!RAW-KNITR-CONTENT{
}RAW-KNITR-CONTENT!!!!!
Save RTF output to a file with gtsave():
my_table |>
gt() |>
gtsave("table.rtf")The resulting .rtf file can be opened in Microsoft Word, LibreOffice Writer, Google Docs, Apple Pages, and many other word processors.
12.3.2 Use cases
RTF output serves these scenarios:
- word processor integration: when tables need editing in Word or similar applications
- cross-platform sharing: RTF files open consistently across Windows, macOS, and Linux
- template population: inserting tables into RTF document templates
- legacy systems: organizations with RTF-based workflows or document management systems
12.3.3 Advantages
RTF offers practical benefits. Nearly every word processor can open RTF files, making them highly portable. Unlike PDFs, RTF tables can be edited after creation. This suits workflows where further refinement in a word processor is expected.
RTF is a text-based format, making it easier to debug or programmatically manipulate than binary formats. No need for Microsoft Office licenses or specific software versions. RTF supports basic formatting like fonts, colors, borders, and cell backgrounds.
12.3.4 Limitations
RTF has notable constraints. Advanced gt features (nanoplots, complex styling, images) may not render correctly or at all. Different word processors interpret RTF slightly differently, potentially causing layout variations.
RTF is a static format without support for interactive elements. It’s also an older format with limited development. Modern document features may not be supported. RTF has less sophisticated styling capabilities than HTML, so some visual effects will be approximated or lost.
12.3.5 Best practices
To work effectively with RTF, use straightforward layouts and basic styling that RTF can reliably represent. If you know which word processor will open the RTF file, test output in that application specifically.
Don’t rely on nanoplots, embedded images, or complex CSS effects when generating RTF. Consider RTF as a format for draft tables that will be refined in a word processor rather than final presentation output.
Always check RTF output after opening in the target word processor, as rendering may differ from expectations.
12.4 Word
Microsoft Word is ubiquitous in business and academic settings. While Word can open HTML and RTF files, gt can also generate tables directly in Word’s native format.
12.4.1 Generating Word output
The simplest way to create Word output is using gtsave() with a .docx extension:
gtcars |>
dplyr::select(mfr, model, hp, msrp) |>
dplyr::slice_head(n = 5) |>
gt() |>
fmt_currency(columns = msrp, decimals = 0) |>
tab_header(title = "Top Cars") |>
gtsave("table.docx")This creates a .docx file with the table embedded as a native Word table. The gt package handles Word export internally without requiring additional packages.
For more complex document assembly with multiple tables and other content, generate individual table files with gtsave() and then import them into a larger Word document using Word’s native import or copy-paste functionality.
12.4.2 Use cases
Word remains the dominant format in many professional settings, making it essential for workflows where compatibility with Microsoft Office ecosystems is expected or required. Understanding when to choose Word output helps ensure your tables reach their audience in the most appropriate format.
Word output is good in corporate and business environments where Word is the standard document format. This includes business reports destined for executives or clients, documents that require review and editing by multiple stakeholders who work primarily in Word, and situations where recipients explicitly require Word format for submission or compliance purposes. The ability to open, review, and comment on tables directly in Word’s familiar interface makes this format ideal for collaborative workflows where non-technical users need to interact with the content.
Word format also serves well when tables are part of larger documents that combine text, images, charts, and other elements. If you’re populating existing Word templates with data tables or assembling reports where tables appear alongside narrative content, the native .docx format ensures smooth integration. The format is particularly valuable when tables need further refinement or customization within Word after initial generation, as recipients can modify table structure, styling, and content using Word’s native table editing tools.
12.4.3 Advantages
Native Word output provides benefits:
Tables are true Word tables, not images or embedded objects, allowing full editing in Word. Tables integrate seamlessly with other Word content such as text, images, charts, page numbers, headers, and footers.
Recipients can view and edit tables using Word’s familiar interface. Word’s collaboration features (track changes, comments) work with the table content.
Tables can be inserted into Word templates with existing styles and formatting. Word’s caption and cross-reference features work with gt-generated tables.
12.4.4 Limitations and best practices
Word format has several constraints. Not all gt features translate to Word. Complex styling may be simplified or lost. Word tables cannot display gt’s nanoplots or embedded visualizations. Recipients need Microsoft Word or compatible software (LibreOffice, Google Docs) to view the tables within .docx files. And different Word versions may render tables slightly differently. The .docx format is complex, and programmatic manipulation of generated Word files requires much care.
For effective Word output, open generated Word files to verify tables appear correctly and formatting is preserved. If you need to create documents with multiple tables and other content, generate individual table files and assemble them in Word, or save tables to intermediate formats that can be imported into your document assembly workflow. It’s better to avoid extremely complex styling that may not translate well to Word’s table model. If recipients will edit tables, structure them for easy modification in Word.
12.5 PNG images
Sometimes you need a table as a static image (either for presentations, infographics, social media posts, or situations where document formats aren’t suitable). The gt package can render tables as PNG images through gtsave().
12.5.1 Generating PNG images
Creating PNG images from gt tables works through a two-step process: the table is first rendered as HTML, then captured as an image using a headless browser. The gt package handles this automatically through its webshot2 dependency, so you don’t need to load any additional packages. However, you do need Chrome or Chromium installed on your system, as webshot2 uses it to render and capture the HTML output. Once these requirements are met, generating PNG images is as simple as using gtsave() with a .png extension:
The gtsave() function detects the .png extension and handles the capture process automatically, determining the optimal image dimensions based on your table’s content and styling.
While the default settings often produce good results, you may want to customize the output for specific purposes. The zoom argument controls the resolution multiplier (think of it as scaling up the rendering before capture). A zoom value of 2 doubles the pixel density, producing higher-resolution images suitable for high-DPI displays or print materials. The default zoom = 1 works well for standard web use where file size matters more than maximum resolution.
The expand argument adds whitespace padding around the table edges, measured in pixels. This prevents the table from butting up against the image boundaries and ensures that borders, shadows, or other edge effects don’t get clipped. The padding applies uniformly to all sides, creating a clean margin that makes the table easier to integrate into presentations or documents:
my_table |>
gtsave(
"table.png",
zoom = 2, # Increase resolution (2x)
expand = 10 # Add padding around table (pixels)
)These two parameters work together to give you precise control over the final image. For a high-resolution table destined for a printed poster, you might use zoom = 3 with expand = 20. For a small social media graphic where file size matters, zoom = 1 with expand = 5 might suffice. The key is matching the output characteristics to your intended use case, balancing image quality against file size constraints.
12.5.2 Use cases
PNG images work well across diverse presentation contexts. They’re ideal for slide decks in PowerPoint, Keynote, or Google Slides where embedding images is straightforward and reliable. Social media posts on Twitter, LinkedIn, and blogs benefit from PNG tables that display consistently regardless of platform rendering quirks. Graphic designers frequently embed PNG tables in infographics and marketing materials, while small summary tables in email signatures provide quick data snapshots. Documentation often requires screenshots of tables, and PNG format serves this need perfectly. Print graphics like posters, flyers, and handouts can incorporate high-resolution PNG tables that reproduce clearly on paper.
12.5.3 Advantages and limitations
PNG images offer universal compatibility as such images can be displayed in any image viewer, web browser, or application that shows images (generally with no rendering variations across platforms). Since PNG captures the HTML rendering, all gt features (nanoplots, complex styling, colors) appear exactly as designed. Recipients need no special software, just basic image viewing capability. You can generate high-resolution images suitable for print or lower-resolution versions optimized for web use, giving you flexibility for different distribution channels.
However, PNG output comes with significant tradeoffs. Images are completely static: no interactivity, hover effects, or ability to select and copy text. Once rendered, the table cannot be edited and any changes require regenerating the entire image. High-resolution images can become quite large, especially for complex tables with many rows. Text in PNG images doesn’t scale like vector text, so zooming reveals pixelation. Accessibility suffers since screen readers cannot extract data from images. Generating PNGs requires Chrome or Chromium, which may not be available in all environments like some server configurations. The rendering process is also slower than generating HTML or text-based formats because it requires launching a headless browser.
12.5.4 Best practices
For optimal results, match your zoom setting to the intended use: use zoom = 2 or higher for high-DPI displays or print output, but stick with zoom = 1 for standard web use where file size matters. Use tab_options() to set table width before rendering, ensuring the table fits your intended layout. The expand argument adds crucial whitespace around table edges, preventing borders or shadows from being clipped (typically 10-20 pixels provides adequate breathing room).
When embedding PNG tables in web content, always provide descriptive alt text for accessibility. If the table will be viewed digitally and you have control over the delivery method, consider whether HTML might better serve your audience by maintaining interactivity and scalability. Reserve PNG format for situations where image format is truly necessary or advantageous, recognizing that you’re trading dynamic features for universal compatibility.
12.6 Choosing the right format
Selecting the optimal output format requires balancing multiple considerations: your distribution channel, your audience’s capabilities, and your table’s complexity. The right choice isn’t always obvious, and sometimes you’ll need to compromise between competing priorities.
The distribution channel can drive initial choices. If your table will appear on a website, blog, or web-based dashboard, HTML is the clear winner here. After all, it’s the web’s native format and provides full feature support including interactivity. Academic publications typically demand LaTeX for PDF generation, as most scholarly journals expect or require LaTeX submission for final typesetting. Business environments often standardize on Word, making .docx output essential for corporate reports regardless of technical superiority of other formats. Presentations present a genuine choice: PNG images work universally in PowerPoint, Keynote, and Google Slides, but HTML tables embedded in R Markdown or Quarto slides preserve interactivity if your presentation platform supports them. Social media usually requires PNG as it’s the only format that displays reliably across all platforms without requiring specialized viewers.
Interactivity requirements can create stark divides. HTML stands alone as the only format supporting hover effects, tooltips, and other dynamic features. If you’ve invested in nanoplots, complex styling, or interactive elements, choosing any format besides HTML means losing those features. PNG preserves the visual appearance but sacrifices all interactivity. Users can’t select text, copy data, or interact with the content (though some operating systems do allow for selection/copying of text). For tables where data extraction matters, HTML, Word, and RTF all allow text selection and copying, while PNG locks everything into pixels. This matters more than you might think: a recipient trying to verify a number or pull data into a spreadsheet will be frustrated by a PNG, while the same table in Word or HTML accommodates that workflow naturally.
Post-creation editing tells you whether to choose editable formats and the Word and RTF formats exist specifically for this scenario. When the table you generate will undergo further modification, refinement, or integration into a larger document by someone else. If stakeholders need to adjust wording, update values, or modify structure, these editable formats are essential. HTML and LaTeX can theoretically be edited, but require technical knowledge that most recipients lack. PNG images are completely immutable. So, any change requires regenerating from the source. For final, finished presentations where no editing is expected or desired, any format works, but immutable formats like PNG prevent well-intentioned but potentially problematic modifications.
Table complexity constrains format choices dramatically. Simple tables with basic formatting translate reasonably well to any format, giving you maximum flexibility. But if your table includes nanoplots, embedded images, or sophisticated styling, your options narrow quickly. HTML handles everything as it’s designed for complex content and rich formatting. PNG captures complex tables perfectly since it’s photographing the HTML rendering, but at the cost of making them static images. LaTeX struggles with modern web-style formatting and won’t render nanoplots or images reliably. Word and RTF sit in the middle: they handle basic styling but choke on advanced features. Tables with mathematical notation push you toward LaTeX, which integrates seamlessly with equation typesetting in a way other formats can’t match.
Your audience’s technical environment matters immensely. PNG works everywhere and literally any device or browser can display images. This universality makes PNG the safe choice when you don’t know what software your audience has. HTML similarly works anywhere with a web browser, though some corporate email systems strip styling that could break layouts. Word requires Microsoft Office or compatible software, which is nearly universal in business but less common in some academic or technical communities. LaTeX presumes recipients have LaTeX expertise (a reasonable assumption in mathematics, physics, and computer science departments). RTF offers the broadest word processor compatibility, but it’s rarely anyone’s first choice for other reasons.
For publication-quality output destined for print, LaTeX produces the most professional typography and precise positioning. High-resolution PNG images can match this quality and work in more contexts, though they lack LaTeX’s mathematical typesetting sophistication. Web display always favors HTML and it’s designed for screens, supports responsive layouts, and allows interactive exploration. For quick reviews, drafts, or iterative feedback, RTF and Word work fine despite their limitations since the goal is communication rather than perfection. Matching format quality to purpose prevents both over-engineering (LaTeX for an internal draft) and under-delivering (RTF for a final publication).
12.7 Extracting formatted cell values for inline use
When writing data-driven documents, you often need to reference specific values from your tables in the surrounding prose. A table might show that sales increased by 23.7%, and you want that same figure to appear in your narrative text: “Our quarterly results showed a 23.7% increase over the previous period”. Traditionally, this creates a reproducibility problem: you calculate the number in R, format it for the table, then manually type it again in your text. If the underlying data changes, you have to remember to update both locations.
The extract_cells() function solves this problem by letting you pull already-formatted cell values directly from a gt table. Whatever formatting you’ve applied (decimal places, currency symbols, percentage signs, scientific notation) comes along with the extracted value. This means your inline references automatically match your table formatting without any additional work. When your data updates, both the table and the prose update together.
12.7.1 Basic extraction
The extract_cells() function takes a gt table and returns formatted cell values based on the column and row you specify:
sales_table <-
tibble::tibble(
region = c("North", "South", "East", "West"),
revenue = c(1234567, 987654, 1567890, 876543),
growth = c(0.237, 0.156, 0.089, 0.312)
) |>
gt(rowname_col = "region") |>
fmt_currency(columns = revenue, decimals = 0) |>
fmt_percent(columns = growth, decimals = 1) |>
cols_label(revenue = "Revenue", growth = "Growth")
sales_table| Revenue | Growth | |
|---|---|---|
| North | $1,234,567 | 23.7% |
| South | $987,654 | 15.6% |
| East | $1,567,890 | 8.9% |
| West | $876,543 | 31.2% |
Now we can extract specific cells. The formatting applied in the table carries through to the extracted value:
# Extract the revenue for the North region
extract_cells(sales_table, columns = revenue, rows = "North")[1] "$1,234,567"# Extract the growth percentage for the West region
extract_cells(sales_table, columns = growth, rows = "West")[1] "31.2%"Notice that the extracted revenue value includes the dollar sign and comma separators, while the growth value includes the percentage sign (exactly as they appear in the table).
12.7.2 Using extracted values in Quarto documents
The real power of extract_cells() emerges in Quarto documents where you can embed R expressions directly in your prose. Instead of hardcoding values, you reference them dynamically:
The North region generated `r extract_cells(sales_table, columns = revenue, rows = "North")`
in revenue, representing `r extract_cells(sales_table, columns = growth, rows = "North")`
year-over-year growth.When this document renders, Quarto evaluates the inline R expressions and inserts the formatted values. If your underlying data changes (e.g., the North region’s revenue updates to "$1,345,678") both the table and the prose automatically reflect the new figure. No manual synchronization required.
This pattern eliminates an entire class of errors. You won’t have the situation where a table shows one number while your text shows a slightly different (outdated or mistyped) version. The single source of truth is your gt table, and extract_cells() lets you tap into it anywhere in your document.
12.7.3 Extracting multiple cells
You can extract multiple cells at once by specifying multiple rows:
# Extract all growth values
extract_cells(sales_table, columns = growth, rows = everything())[1] "23.7%" "15.6%" "8.9%" "31.2%"The result is a character vector with one element per extracted cell. This is useful when you need to reference a range of values or when building dynamic text that incorporates multiple data points.
You can also combine extraction with row selection expressions:
# Extract revenue for regions with growth over 20%
extract_cells(sales_table, columns = revenue, rows = growth > 0.2)[1] "$1,234,567" "$876,543" 12.7.4 Output format considerations
The extract_cells() function includes an output argument that controls how the extracted values are formatted. By default (output = "auto"), it detects the rendering context and chooses appropriately:
- in Quarto HTML documents, it returns HTML-formatted values
- in PDF documents (via LaTeX), it returns LaTeX-formatted values
- in Word documents, it returns Word-compatible formatting
- in the R console, it returns plain text
You can override this behavior when needed:
# Force plain text output (strips HTML/LaTeX markup)
extract_cells(sales_table, columns = revenue, rows = "North", output = "plain")[1] "$1,234,567"# Force HTML output (useful for manual HTML document construction)
extract_cells(sales_table, columns = revenue, rows = "North", output = "html")[1] "$1,234,567"The automatic detection works correctly in most situations, but explicit output specification helps when you’re generating content for a specific format or when the automatic detection doesn’t match your needs.
12.8 Format conversion strategies
Sometimes you need the same table in multiple formats. Here’s an approach where we generate one table and save in multiple formats:
my_table <- gtcars |>
dplyr::select(mfr, model, msrp) |>
dplyr::slice_head(n = 5) |>
gt() |>
fmt_currency(columns = msrp)
# Save in multiple formats
my_table |> gtsave("table.html")
my_table |> gtsave("table.png")
my_table |> gtsave("table.rtf")The approach above works well when the same table design translates adequately across all formats. But as we’ve discussed throughout this chapter, different formats have different capabilities and constraints. HTML supports nanoplots and complex styling. LaTeX and RTF cannot do nanoplots and they struggle with complex styling. PNG captures everything visually but sacrifices interactivity. Word sits somewhere in the middle with moderate feature support.
When you need the same table in multiple formats but want each version optimized for its target medium, conditional rendering lets you adjust table construction based on the destination format. Instead of creating one table and hoping it works everywhere, you make intelligent decisions about which features to include, which styling to apply, and how to structure the table based on where it’s going. This prevents LaTeX compilation errors from unsupported features, keeps RTF files simple and reliable, and reserves advanced features for formats that can handle them.
Here’s a function that demonstrates format-conditional table generation:
generate_table <- function(data, format = "html") {
# Create base table with data
base_table <-
data |>
gt() |>
tab_header(title = "Vehicle Performance Data")
# Format-specific adjustments
if (format == "html") {
# HTML gets full styling and nanoplots (if data available)
if ("mpg_data" %in% names(data)) {
base_table <-
base_table |>
cols_nanoplot(columns = mpg_data, new_col_name = "mpg_plot")
}
base_table <-
base_table |>
fmt_number(columns = where(is.numeric), decimals = 1) |>
tab_style(
style = cell_fill(color = "lightblue"),
locations = cells_body(columns = hp)
)
} else if (format %in% c("latex", "rtf", "word")) {
# LaTeX, RTF, and Word: skip nanoplots, use simpler formatting
base_table <-
base_table |>
fmt_number(columns = where(is.numeric), decimals = 1)
}
# Save with appropriate extension
gtsave(base_table, filename = paste0("table.", format))
}This function creates a base table, then applies format-specific adjustments before saving. The conditional logic recognizes that HTML can handle advanced features like nanoplots and complex styling, while LaTeX, RTF, and Word all receive the same simpler treatment focused on reliable data formatting. These three formats share similar limitations as none can render nanoplots effectively, and all benefit from conservative styling that translates predictably. You’d call this function with your data and desired format: generate_table(my_data, "html"), generate_table(my_data, "latex"), generate_table(my_data, "word").
The real power emerges when you extend this pattern for sophisticated format-specific optimizations. For HTML output, you might add nanoplots, interactive tooltips via fmt() functions with custom HTML, and complex CSS styling through tab_style(). For LaTeX, you’d skip the nanoplots entirely, use simpler column alignments, and reduce border complexity. For Word, you might adjust column widths or apply specific formatting knowing that Word’s table rendering differs from browsers, though still avoiding features it can’t handle. For PNG, you could increase font sizes slightly since the image will be static and needs to remain readable at various scales.
The function could also handle format-specific data presentations. Maybe HTML gets sparklines showing trends, while LaTeX gets a simpler “change” column with up/down arrows using Unicode characters that render reliably in LaTeX. Perhaps Word output includes page number indicators or section references that make sense in document context, while standalone PNG images omit those references since they’ll be viewed in isolation. You might even use completely different data subsets: HTML gets the full interactive table with hundreds of rows, while PDF gets a summarized version focusing on key findings.
This conditional approach prevents the lowest-common-denominator problem where you limit all formats to what the weakest format can handle. Instead, each format gets a table optimized for its strengths and constraints.
12.9 Conclusion
The ability to generate tables in multiple formats transforms gt from a web-focused tool into a truly universal table creation system. A single table definition can reach audiences across academic papers, business reports, web dashboards, presentations, and social media. Each version is optimized for its destination while maintaining the core data and structure.
Understanding format capabilities matters more than memorizing feature lists. HTML’s complete feature support makes it the default choice for digital distribution, but that power becomes irrelevant when your audience needs a Word document for collaborative editing or when journal submission requires LaTeX. The format you choose is rarely about technical superiority, it’s more about matching your table to your audience’s constraints, expectations, and workflows.
The trade-offs between formats follow predictable patterns. Formats that support editing (Word, RTF) sacrifice advanced features. Formats that preserve complex visualizations (HTML, PNG) limit portability or editability. Formats optimized for print quality (LaTeX, high-resolution PNG) require more setup and expertise. These aren’t limitations to work around but inherent characteristics to understand and leverage. When you know what each format does well and what it struggles with, you can make informed decisions rather than discovering constraints through trial and error.
Format-specific optimization represents the professional approach to multi-format publishing. Rather than creating one table and hoping it works everywhere, you design deliberately for each format’s strengths while accepting its limitations. HTML gets nanoplots and rich styling. LaTeX gets clean typography and mathematical integration. Word gets editable structure for collaborative refinement. PNG gets universal compatibility at the cost of becoming static. Each format receives what it can handle effectively, and nothing it will render poorly or not at all.
The next time you create a table, consider where it will ultimately appear. That destination, not the table’s content, should drive your format choice. A brilliant HTML table with nanoplots and interactive features becomes frustrating when shared as an image on social media where users can’t copy the data. An overengineered LaTeX table in an internal draft wastes time that simpler RTF output would serve better. The best table isn’t the most technically sophisticated one. Rather it’s the one that works effectively in its intended context for its intended audience.