View source: R/modify_table_styling.R
modify_table_styling | R Documentation |
This is a function meant for advanced users to gain
more control over the characteristics of the resulting
gtsummary table by directly modifying .$table_styling
.
This function is primarily used in the development of other gtsummary
functions, and very little checking of the passed arguments is performed.
modify_table_styling(
x,
columns,
rows = NULL,
label = NULL,
spanning_header = NULL,
hide = NULL,
footnote = NULL,
footnote_abbrev = NULL,
align = NULL,
missing_symbol = NULL,
fmt_fun = NULL,
text_format = NULL,
undo_text_format = NULL,
indent = NULL,
text_interpret = c("md", "html"),
cols_merge_pattern = NULL
)
x |
( |
columns |
( |
rows |
(predicate |
label |
( |
spanning_header |
( |
hide |
(scalar |
footnote |
( |
footnote_abbrev |
( |
align |
( |
missing_symbol |
( |
fmt_fun |
( |
text_format , undo_text_format |
( |
indent |
( |
text_interpret |
( |
cols_merge_pattern |
( |
Review the
gtsummary definition
vignette for information on .$table_styling
objects.
The rows argument accepts a predicate expression that is used to specify
rows to apply formatting. The expression must evaluate to a logical when
evaluated in x$table_body
. For example, to apply formatting to the age rows
pass rows = variable == "age"
. A vector of row numbers is NOT acceptable.
A couple of things to note when using the rows
argument.
You can use saved objects to create the predicate argument, e.g.
rows = variable == letters[1]
.
The saved object cannot share a name with a column in x$table_body
.
The reason for this is that in tbl_merge()
the columns are renamed,
and the renaming process cannot disambiguate the variable
column from
an external object named variable
in the following expression
rows = .data$variable = .env$variable
.
There are planned updates to the implementation of column merging.
Currently, this function replaces the numeric column with a
formatted character column following cols_merge_pattern=
.
Once gt::cols_merge()
gains the rows=
argument the
implementation will be updated to use it, which will keep
numeric columns numeric. For the vast majority of users,
the planned change will be go unnoticed.
If this functionality is used in conjunction with tbl_stack()
(which
includes tbl_uvregression()
), there is potential issue with printing.
When columns are stack AND when the column-merging is
defined with a quosure, you may run into issues due to the loss of the
environment when 2 or more quosures are combined. If the expression
version of the quosure is the same as the quosure (i.e. no evaluated
objects), there should be no issues. Regardless, this argument is used
internally with care, and it is not recommended for users.
See gtsummary internals vignette
Other Advanced modifiers:
modify_column_indent()
,
modify_column_merge()
Add the following code to your website.
For more information on customizing the embed code, read Embedding Snippets.