Benchmark setup

The goal was to compare the document generation engines rather than data preparation or statistical computation.

A realistic laboratory listing dataset was generated with dummy data containing: 10 investigative sites, 20 subjects per site, Subject demographics (Age and Sex), Laboratory category (Chemistry and Hematology), Laboratory parameter, Assessment date, Visit, Laboratory result, Unit, and Low / Normal / High indicator

   SITE         USUBJID AGE SEX     LBCAT     LBTEST      LBDTC     VISIT LBORRES LBORRESU LBNRIND
1   001 ABC-101-001-001  31   M Chemistry        ALT 2024-02-20 Screening   124.0      U/L  NORMAL
2   001 ABC-101-001-001  31   M Chemistry        AST 2024-02-20 Screening    66.0      U/L  NORMAL
3   001 ABC-101-001-001  31   M Chemistry        ALP 2024-02-20 Screening   111.9      U/L  NORMAL
4   001 ABC-101-001-001  31   M Chemistry  Bilirubin 2024-02-20 Screening   130.5   umol/L  NORMAL
5   001 ABC-101-001-001  31   M Chemistry    Albumin 2024-02-20 Screening    89.2      g/L  NORMAL
6   001 ABC-101-001-001  31   M Chemistry Creatinine 2024-02-20 Screening   124.0   umol/L  NORMAL
7   001 ABC-101-001-001  31   M Chemistry       Urea 2024-02-20 Screening   140.0   mmol/L     LOW
8   001 ABC-101-001-001  31   M Chemistry    Glucose 2024-02-20 Screening   113.6   mmol/L  NORMAL
9   001 ABC-101-001-001  31   M Chemistry        ALT 2024-06-03  Baseline   101.8      U/L  NORMAL
10  001 ABC-101-001-001  31   M Chemistry        AST 2024-06-03  Baseline   115.6      U/L  NORMAL

The following functions were created to run with the bench package.

library(reporter)

reporter_bench <- function(nrows) {

tbl <- create_table(lab |> head(nrows)) |>
    page_by(SITE,   label="Site: ") |>
    define('SITE', visible = F) |>
    define('USUBJID', dedupe = T)

rpt <-
    create_report(
        "Reporter_LabListing.rtf",  output_type="RTF",
        font="Courier", font_size=8
    ) |>
    page_header(
        left="ABC-101",
        center="Laboratory Listing",
        right="CSR"
    ) |>
    titles("Listing 14.3.1","Laboratory Results Listings by Site"   ) |>
    add_content(tbl) |>
    footnotes(
        "LOW = Below reference range",
        "HIGH = Above reference range"
    ) |>
    page_footer(
        left=format(Sys.Date()),
        center="Confidential",
        right="Page [pg] of [tpg]"
    )

    write_report(rpt)
    
}

library(ksTFL)

ksTFL_bench <- function(nrows) {

data <- lab |> head(nrows)

listing <- create_table(data) |>
    add_header( c("ABC-101","Laboratory Listing","CSR")) |>
  add_footer(c(format(Sys.Date()), "Confidential", "Page {PAGE} of {NUMPAGES}")) |>
    add_title(c("Listing 14.3.1",   "Laboratory Results Listings by Site")) |>
    add_subtitle("Site: #ByGroup1") |>
    add_footnote(c("LOW = Below reference range", "HIGH = Above reference range")) |>
    define_cols(SITE, isVisible = F, isGrouping = T) |>
    define_cols(USUBJID, dedupe = T)

rep <- create_report(listing)
write_doc(rep, 'ksTFL_LabListing')

}

library(bench)

sizes <- c(1000, 3000, 10000, 20000)

results <-
    bind_rows(
        lapply(sizes, function(n) {
            
            cat("Benchmarking", n, "rows...\n")
            
            x <-
                bench::mark(
                    Reporter = reporter_bench(n),
                    ksTFL    = ksTFL_bench(n),
                    iterations = 2,
                    check = FALSE,
                    memory = TRUE,
                    time_unit = "s"
                )
            
            x$nrows <- n
            
            x
        })
    )

What stands out?

The difference is immediately noticeable.

Even for a relatively small listing of 1,000 rows, ksTFL completed report generation in just over 100 milliseconds, while Reporter required almost 3 seconds.

As the listing size increased, the performance gap widened considerably.

For 20,000 rows, Reporter required more than one and a half minutes to generate the report, whereas ksTFL completed the same task in just over one second.

More interestingly, the advantage isn’t constant—it increases dramatically with report size. Rather than maintaining a fixed performance lead, ksTFL’s advantage actually grows as datasets become larger, as illustrated below:

The chart reveals a consistent upward trend: at 1,000 rows, ksTFL is 28× faster; this advantage grows to 41× at 3,000 rows, 50× at 10,000 rows, and 73× at 20,000 rows. This non-linear relationship is the hallmark of a reporting engine that scales with computational efficiency.

Memory usage tells an even bigger story

Execution time is only part of the picture.

The amount of memory allocated during report generation increases rapidly for Reporter as the listing becomes larger. For the largest benchmark Reporter allocated nearly 50 GB of memory while ksTFL required only 38 MB.

This dramatic disparity grows more severe as dataset size increases:

As shown in the chart, Reporter’s memory consumption grows exponentially with dataset size—scaling from 125 MB at 1,000 rows to over 50 GB at 20,000 rows. In contrast, ksTFL’s memory footprint remains consistently modest across all tested sizes, growing from less than 1 MB to just 38 MB.

Lower memory consumption isn’t just an interesting benchmark statistic. It means:

• reduced risk of exhausting available memory,

• better performance on virtual machines and shared servers,

• and the ability to generate multiple reports in parallel without competing for system resources.

Why does this matter?

In real-world clinical reporting, the document generation step is only one part of the overall workflow. Data preparation, derivations and statistical analyses often account for a large proportion of the total runtime.

However, once the analysis datasets are ready, the reporting engine becomes the final stage and sometimes repeated over and over again.

During study development, programmers regenerate reports after every change, QC programmers independently recreate the same outputs, and complete production runs are repeated for interim analyses, database updates and final deliverables.

A study containing a few hundred outputs may therefore generate thousands of report files over its lifetime.

Even if each individual report saves only a few seconds, those savings accumulate into hours of reduced waiting time for programmers and much faster production cycles.

Final thoughts

Performance isn’t the only criterion when selecting a reporting framework. Functionality, output quality, flexibility and ease of use are equally important.

Nevertheless, report generation speed becomes increasingly valuable as studies become larger and reporting workflows become more automated.

One particularly interesting observation from this benchmark is that the performance advantage of ksTFL grows as report size increases. Rather than maintaining a constant lead, ksTFL becomes progressively faster relative to Reporter while simultaneously requiring dramatically less memory.

Although this benchmark focuses on a laboratory listing, the results indicate that the underlying document generation engine scales efficiently and remains responsive even for substantially larger reports.

If your reporting workflow involves generating hundreds of outputs throughout the lifetime of a clinical trial, those gains can translate into noticeably shorter development cycles, faster production runs, and a smoother experience for the programming team.

Benchmark environment: Both packages were executed on the same machine using the same input data and comparable report layouts. Each benchmark was run twice, with the median execution time reported. The benchmark was designed to measure the performance of the reporting engine itself, not the time required for data preparation or statistical analyses. The measurements were done using reporter version 1.4.7, and ksTFL version 0.11.9.

Aleschenkov I, Larchenko V (2026). _ksTFL: Framework for Clinical Tables,
  Figures, and Listings_. R package version 0.11.9,
  <https://crow16384.github.io/ksTFL/,https://crow16384.r-universe.dev/ksTFL>

This post was originally published on the KeyStat Solutions R Technical Blog. Visit R-Bloggers to discover more R content.

1. Protocol windows and subject-specific buckets

A common clinical-trials task is mapping visit-day values into protocol-defined windows. The same idea extends to arm-specific rules, where one stratum has a slightly different window structure from another.

windows <- fmap_strata(
  stratum = c("ARM_A", "ARM_A", "ARM_A", "ARM_B", "ARM_B"),
  low     = c(0,        7,       28,      0,       14),
  high    = c(7,        28,      Inf,     14,      Inf),
  label   = c("Baseline", "Wk1-3", "Wk4+", "Baseline", "Wk2+"),
  inc_high = c(FALSE, FALSE, TRUE, FALSE, TRUE)
)

fnew(
  windows,
  type = "stratified_range",
  name = "visit_window",
  .other = "Outside window"
)

visit_df <- tibble(
  arm = c("ARM_A", "ARM_A", "ARM_B", "ARM_B", "ARM_C"),
  day = c(3, 35, 5, 40, 10)
) |> mutate(
  window = fputk(arm, day, format = "visit_window"),
)

visit_df

# A tibble: 5 × 3
  arm     day window        
  <chr> <dbl> <chr>         
1 ARM_A     3 Baseline      
2 ARM_A    35 Wk4+          
3 ARM_B     5 Baseline      
4 ARM_B    40 Wk2+          
5 ARM_C    10 Outside window

This is useful for:

• visit window derivation in ADaM outputs
• protocol deviation checks
• windowed endpoint calculations

2. Composite keys for clinical mappings

Clinical trial data often uses multi-column logic: lab category + test code + unit, or population + analysis flag + visit type. fputk() can build a lookup from multiple fields without manually concatenating in the analysis step.

fnew(
  fmap(
    paste(
      c("BLOOD CHEMISTRY", "COAGULOGRAM", "COAGULATION PANEL", "COAGULOGRAM"),
      c("BLOOD",           "BLOOD",        "BLOOD",             "BLOOD"),
      c("ALB",             "FIBRINO",      "INR",               "INR"),
      c("g/L",             "g/L",           NA,                  NA),
      sep = "|"
    ),
    c("ALB", "FIBRINO", "INR", "INR")
  ),
  type = "character",
  name = "lb_param",
  ignore_case = TRUE,
  .other = NA
)

lab_df <- tibble(
  LBCAT = c("BLOOD CHEMISTRY", "COAGULOGRAM", "COAGULATION PANEL"),
  LBSPEC = c("BLOOD", "BLOOD", "BLOOD"),
  LBTESTCD = c("ALB", "INR", "INR"),
  LBSTRESU = c("g/L", NA, NA)
) |> mutate(
  PARAMCD = fputk(LBCAT, LBSPEC, LBTESTCD, LBSTRESU, format = "lb_param", na_as_string = TRUE)
)

lab_df

# A tibble: 3 × 5
  LBCAT             LBSPEC LBTESTCD LBSTRESU PARAMCD
  <chr>             <chr>  <chr>    <chr>    <chr>  
1 BLOOD CHEMISTRY   BLOOD  ALB      g/L      ALB    
2 COAGULOGRAM       BLOOD  INR      <NA>     INR    
3 COAGULATION PANEL BLOOD  INR      <NA>     INR    

The same pattern is useful for:

• AE grouping by term + severity + relation
• CM coding by medication + route + dose form
• endpoint derivations from multiple source fields

3. Reverse lookup for QC and cleaning

finputk() is helpful when raw labels must be normalized back to codes. In clinical programming, that makes it suitable for QC checks, mapping vendor text, and validating reviewer-facing labels.

finput(
  fmap(
    paste(c("PLACEBO", "DRUG A", "DRUG B"), c("PBO", "A50", "B100"), sep = "|"),
    c(1L, 2L, 3L)
  ),
  target_type = "integer",
  name = "trt_code_inv"
)

KS Invalue: trt_code_inv
Target Type: integer 
Mappings:
  PLACEBO|PBO => 1
  DRUG A|A50 => 2
  DRUG B|B100 => 3

trt_df <- tibble(
  ARMN = c("PLACEBO", "DRUG A", "DRUG B", "UNKNOWN"),
  TRTCD = c("PBO", "A50", "B100", "X")
) |> mutate(
  TRTSEQ = finputk(ARMN, TRTCD, invalue_name = "trt_code_inv")
)

trt_df

# A tibble: 4 × 3
  ARMN    TRTCD TRTSEQ
  <chr>   <chr>  <int>
1 PLACEBO PBO        1
2 DRUG A  A50        2
3 DRUG B  B100       3
4 UNKNOWN X         NA

Typical uses include:

• deriving internal codes from decoded labels in QC datasets
• validating data entry against controlled terminology
• reconciling spreadsheet exports back to source codes

4. Report-ready numeric formatting

ksformat can also be used where report output needs consistent numeric presentation. This is not a lookup table; it is a pattern-driven formatter.

fnew("$%,.2f", type = "numeric", name = "currency")
fnew("%.1f%%", type = "numeric", name = "pct")

summary_df <- tibble(
  metric = c("Cost", "Response rate"),
  raw = c(1234.56, 0.153)
) |> mutate(
  display = c(fputn(raw[1], "currency"), fputn(raw[2] * 100, "pct"))
)

summary_df

# A tibble: 2 × 3
  metric             raw display  
  <chr>            <dbl> <chr>    
1 Cost          1235.    $1,234.56
2 Response rate    0.153 15.3%    

Same result could be achieved using expression labels, but in base R, sprintf() itself does not support thousands separators such as commas. We can use formatC for the formatting purposes. Pattern-driven formatter looks simplier for such case.

stat_fmt <- fnew(
  #"currency"   = "sprintf('$%,.2f', .x1)", # Will not work!
  "currency"   = "formatC(.x1, digits = 2, big.mark = ',', format = 'f', decimal.mark = '.')",
  "pct" = "sprintf('%.1f%%', .x1 * 100)",
  name = "stat",
  type = "character"
)

summary_df <- tibble(
  metric = c("Cost", "Response rate"),
  raw = c(1234.56, 0.153),
  format = c("currency","pct")
) |> mutate(
  display = fput(format, stat_fmt, raw)
)

summary_df

# A tibble: 2 × 4
  metric             raw format   display 
  <chr>            <dbl> <chr>    <chr>   
1 Cost          1235.    currency 1,234.56
2 Response rate    0.153 pct      15.3%   

This is useful for:

• CSR and TLF output generation
• QA listings for counts and rates
• ad hoc review tables where consistent display matters

5. Bucketing dates into operational periods

Clinical teams often work with periods such as screening, treatment, follow-up, and analysis cut-offs. date_range and datetime_range let you keep those rules in one place instead of duplicating them in ad hoc code.

fparse(text = '
VALUE study_period (date_range)
  [2024-01-01, 2024-02-01) = "Screening"
  [2024-02-01, 2024-06-01) = "Treatment"
  [2024-06-01, HIGH]       = "Follow-up"
  .missing                 = "No date"
;
')

obs_dates <- as.Date(c("2024-01-15", "2024-03-10", "2024-07-01", NA))
tibble(
  date = obs_dates,
  period = fput(obs_dates, "study_period")
)

# A tibble: 4 × 2
  date       period   
  <date>     <chr>    
1 2024-01-15 Screening
2 2024-03-10 Treatment
3 2024-07-01 Follow-up
4 NA         No date  

6. Text generation for listings and narratives

Expression labels make ksformat useful for building small text fragments in reports. In clinical settings, that can be handy for reviewer comments, summary phrases, or footnotes.

fnew(
  "high" = "sprintf('Above threshold: %s', .x1)",
  "low" = "sprintf('Below threshold: %s', .x1)",
  name = "thr_note"
)

fput(c("high", "low"), "thr_note", c(18.2, 7.4))

[1] "Above threshold: 18.2" "Below threshold: 7.4" 

This is especially useful when the label depends on:

• a measurement value
• a threshold or cohort-specific cutoff
• an external text fragment such as a reviewer comment

7. Practical cautions

These patterns are powerful, but they work best when the mapping rules are stable and owned by the analysis team. A few guardrails help:

• keep the format definition close to the analysis spec
• prefer a named format for rules reused across tables and datasets
• use fclear() in examples and tests to avoid leaking state between steps
• use na_as_string = TRUE only when the key was built with literal "NA" components from paste()

8. fparse() syntax for all format families

If you want to express fnew()-style rules as text, fparse() supports the same VALUE/INVALUE families as the package parser. The main idea is:

• use VALUE for forward lookup formats
• use INVALUE for reverse lookup formats
• use pattern = ... only for date/time/datetime formats
• use pattern: ... in the VALUE header for numeric display patterns
• use interval syntax for numeric, date, datetime, and stratified ranges

fparse(text = '
VALUE sex (character)
  "M" = "Male"
  "F" = "Female"
  .missing = "Unknown"
  .other = "Other"
;

VALUE age_group (numeric)
  [0, 18)    = "Child"
  [18, 65)   = "Adult"
  [65, HIGH] = "Senior"
;
')

fparse(text = '
INVALUE sex_inv
  "Male" = "M"
  "Female" = "F"
  .missing = "U"
;
')

fparse(text = '
VALUE enrldt (date)
  pattern = "DATE9."
  .missing = "Not Enrolled"
;

VALUE visit_time (time)
  pattern = "TIME8."
;

VALUE stamp (datetime)
  pattern = "DATETIME20."
;
')

fparse(text = '
VALUE currency (numeric, pattern: "$%,.2f")
  .missing = "NO DATA"
;

VALUE pct (numeric, pattern: "%.1f%%")
;
')

tibble(
  raw = c(1234.56, -7890.12, 0, NA),
  currency = fputn(c(1234.56, -7890.12, 0, NA), "currency"),
  pct = fputn(c(0, 12.3, -4.5, NA), "pct")
)

# A tibble: 4 × 3
     raw currency   pct  
   <dbl> <chr>      <chr>
1  1235. $1,234.56  0.0% 
2 -7890. -$7,890.12 12.3%
3     0  $0.00      -4.5%
4    NA  NO DATA    <NA> 

fparse(text = '
VALUE study_period (date_range)
  [2024-01-01, 2024-02-01) = "Screening"
  [2024-02-01, 2024-06-01) = "Treatment"
  [2024-06-01, HIGH]       = "Follow-up"
;

VALUE shift (datetime_range)
  [2024-01-15 00:00, 2024-01-15 08:00) = "Night"
  [2024-01-15 08:00, 2024-01-15 16:00) = "Day"
  [2024-01-15 16:00, 2024-01-16 00:00) = "Evening"
;
')

fparse(text = '
VALUE visit_window (stratified_range, range_subtype: numeric)
  "ARM_A"|[0, 7)     = "Baseline"
  "ARM_A"|[7, 28)    = "Wk1-3"
  "ARM_B"|[0, 14)    = "Baseline"
  .other              = "Outside"
;
')

fnew("$%,.2f", type = "numeric", name = "currency_direct")
fputn(c(1234.56, -7890.12, 0), "currency_direct")

[1] "$1,234.56"  "-$7,890.12" "$0.00"     

Conclusion

ksformat is not limited to simple code-to-label dictionaries. In clinical trials it can also serve as a compact rule engine for visit windows, composite keys, reverse mappings, report formatting, and small narrative fragments. That makes it useful anywhere repeated conditional logic would otherwise be spread across scripts, spreadsheets, or one-off helper functions.

fclear()

All formats cleared from library.

Larchenko V, Aleschenkov I (2026). _ksformat: 'SAS'-Style 'PROC FORMAT'   for R_. R package version 0.8.3, <https://github.com/crow16384/ksformat>.

This post was originally published on the KeyStat Solutions R Technical Blog. Visit R-Bloggers to discover more R content.

Why ksTFL?

Clinical trial deliverables require:

• ✅ Professional formatting and alignment with regulatory standards
• ✅ Reproducible, auditable code
• ✅ Traceability of the data throughout the analysis pipeline
• ✅ Submission-ready output without manual refinement

Without a specialized tool, generating submission-ready tables and figures from R can require significant time—sometimes more than the time spent on statistical calculations and modeling itself.

Installation

Install ksTFL from r-universe:

Your First Table

Let’s create a simple demographic summary table using sample data:

# Use built-in mtcars dataset for simplicity
spec <- create_table(mtcars, cols = c(cyl, mpg, hp, wt)) |>
  add_title("Motor Trend Car Road Tests", styleRef = "i") |>
  add_title("Performance Metrics by Cylinder Count", styleRef = "i") |>
  add_footnote("Source: 1974 Motor Trend US magazine")

# Define columns with labels and styling
spec <- spec |>
  define_cols(c(mpg, hp, wt), 
              label = c("Miles/(US) gallon", "Horsepower", "Weight<br>(1000 lbs)"),
              valueStyleRef = "ac"  # align center
              ) |>
  define_cols(cyl, 
                        label = "N of Cylinders",
              dedupe = T) |>
    set_document(contentWidth = "60%")

# Create report and render to DOCX
report <- create_report(spec)
write_doc(report, name = "demo_table", outDir = "output")

Key Features

# Add conditional styling - highlight high horsepower
spec <- spec |>
  compute_cols(hp >=180, 
               c_style(hp, styleRef = "fc_red"))  # font color red

spec <- spec |>
  add_span_header(cols = c(mpg, hp, wt), 
                  label = "Performance Metrics")

spec |>
  define_cols(starts_with("m"), 
              valueStyleRef = "ar")  # right align

# Combine multiple style attributes
spec <- add_title(spec, "Summary", 
                  styleRef = f_combine("i", "b", "fc_navy"))

Complete Example: Demographics Table

Let’s build a submission-ready demographics table.

Since this article focuses on ksTFL’s rendering capabilities, the statistical calculations and data preparation are handled upstream. ksTFL does not calculate statistics by itself; rather, it transforms pre-calculated summary tables into publication-ready documents. In production code, statisticians prepare the summary data in a planar format, and ksTFL handles the table layout and formatting.

Below, we use a simple function that generates a data frame with calculated statistics for Age, Sex, and Race:

# Simple function that generates the summary table
# that a statistical programmer typically creates from ADSL data
generate_demography_summary <- function(seed = 1007L) {
    set.seed(seed)
    
    rnd_stat <- function(N) {
        c(
            sprintf("%.1f (%.1f)", rnorm(1L, 48, 2), rnorm(1L, 11, 1)),
            sprintf("%.1f", rnorm(1L, 49, 2)),
            sprintf("%d, %d", sample(20:30, 1L), sample(65:75, 1L)),
            sprintf("%d (%.1f%%)", 22L, 100 * 22L / N),
            sprintf("%d (%.1f%%)", 20L, 100 * 20L / N),
            sprintf("%d (%.1f%%)", 28L, 100 * 28L / N),
            sprintf("%d (%.1f%%)", 9L, 100 * 9L / N),
            sprintf("%d (%.1f%%)", 5L, 100 * 5L / N)
        )
    }
    
    data.frame(
        PARAM = c(rep("Age (years)",3), rep("Sex",2), rep("Race",3)),
        STATISTIC = c("Mean (SD)", "Median", "Min, Max", 
                                    "Female", "Male", 
                                    "White", "Asian", "Other"),
        PLACEBO = rnd_stat(placebo_n),
        DRUGA = rnd_stat(drug_a_n),
        TOTAL = rnd_stat(total_n),
        stringsAsFactors = FALSE
    )
}

With the inputs provided above, the generated data frame looks like this:

placebo_n <- 42L
drug_a_n <- 44L
total_n <- placebo_n + drug_a_n

table_data <- generate_demography_summary(seed = 1007L)

table_data

        PARAM STATISTIC     PLACEBO      DRUGA       TOTAL
1 Age (years) Mean (SD) 49.0 (11.3) 48.6 (9.8) 51.6 (12.1)
2 Age (years)    Median        51.6       47.9        50.2
3 Age (years)  Min, Max      26, 68     20, 75      26, 69
4         Sex    Female  22 (52.4%) 22 (50.0%)  22 (25.6%)
5         Sex      Male  20 (47.6%) 20 (45.5%)  20 (23.3%)
6        Race     White  28 (66.7%) 28 (63.6%)  28 (32.6%)
7        Race     Asian   9 (21.4%)  9 (20.5%)   9 (10.5%)
8        Race     Other   5 (11.9%)  5 (11.4%)    5 (5.8%)

Now let’s use ksTFL to transform this planar data frame into a submission-ready document:

# Initialize ksTFL table specification
table_spec <- create_table(table_data) |>
    # PARAM is set to invisible because we use it as a category header.
    # This keeps the table compact and maintains a professional appearance.
    define_cols(PARAM, label = "Parameter", isVisible = FALSE) |>
    # STATISTIC remains visible on every row because it distinguishes
    # different statistics within each parameter block.
    define_cols(STATISTIC, 
                    label = "Parameter<br>Statistic", 
                    valueStyleRef = "indent_1", labelStyleRef = 'al') |>
    # Treatment columns follow the same display rules, so we define them together.
    # Although ksTFL calculates column widths automatically,
    # we manually set them here to ensure consistent treatment column widths
    # across the output for visual clarity and professional presentation.
    define_cols(c(PLACEBO, DRUGA, TOTAL),
                            label = c(paste0("Placebo<br>(N=", placebo_n,')'), 
                                                paste0("Drug A<br>(N=", drug_a_n,')'), 
                                                paste0("Total<br>(N=", total_n,')')),
                            valueStyleRef = "ac",
                            colWidth = c("18%", "18%", "18%")
    ) |>
    compute_cols(
    # The input data lacks units for categorical statistics;
    # we add them dynamically here.
        PARAM %in% c('Sex', 'Race'),
        c_glue(PARAM, 'after', text=', n (%)')
    ) |>
    # Use PARAM values as heading rows for better structure
    compute_cols(
        firstOf(PARAM),
        c_addrow('above', value_from = PARAM, styleRef = f_combine('al', 'b'))
    ) |>
    # Define titles, subtitles, and document headers/footers
    add_title("Table 14.1 Demographic Summary") |>
    add_subtitle("(Safety Population)", styleRef = 'ac') |>
    add_footnote("Note: Values are presented as summary statistics prepared before the ksTFL stage.") |>
    add_header("Example Study KSTFL-107", "DEMOGRAPHY", "Page {PAGE} of {NUMPAGES}") |>
    add_footer("Basic summary table example", "", format(Sys.Date(), "%Y-%m-%d")) |>
    # Demographic tables benefit from a moderate content width:
    # narrow enough to keep treatment columns readable, but wide enough
    # to avoid sparse layouts with few rows.
    set_document(
        contentWidth = "50%",
        # ksTFL provides flexible control over footnote placement:
        # "doc_footer" (in the Word footer below footer rows),
        # "repeated" (under the table on every page), or
        # "last_page" (under the table on the last page only)
        footnotePlace = "doc_footer" 
    )

# Create report and render to DOCX
report <- create_report(table_spec)

write_doc(report, name = "table_14_1", outDir = "output")

With just a few lines of declarative code, the planar data frame transforms into a production-ready document:

The key advantage of this approach is that the input data remains in a simple, planar format that is easy to validate and audit, without any embedded reporting artifacts or formatting logic.

Next Steps

Now that you understand the basics of ksTFL, you can:

- Explore the ksTFL Documentation for advanced features

- Check out the GitHub Repository for more real examples and scripts

- A LinkedIn Post here gives some additional context and background on the ksTFL package.

Aleschenkov I, Larchenko V (2026). ksTFL: Framework for Clinical Tables, Figures, and Listings. R package version 0.11.9, https://crow16384.github.io/ksTFL/ https://crow16384.r-universe.dev/ksTFL.

This post was originally published on the KeyStat Solutions Technical Blog. Visit R-Bloggers to discover more R content.