-
-
Notifications
You must be signed in to change notification settings - Fork 147
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support tabularray
#804
Support tabularray
#804
Conversation
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This PR is ready for a first review. Note that this code should not make any change to existing behavior. The new functions are triggered only by the kbl(dat, tabular = "tblr")
kbl(dat, tabular = "talltblr")
kbl(dat, tabular = "longtblr") If @haozhu233 or @dmurdoch are interested, I wrote a detailed vignette to highlight the main features and workflow: I am super excited about this. As noted in the vignette, this helps us solve at least 7 thorny bugs (and probably more), and it opens up a lot of cool possibilities for LaTeX tables. Row and column processing via regexes should eventually be much more robust, because we only need to manipulate the "header" of a table and not its individual cells. |
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
@dmurdoch, thanks for looking at this. I really appreciate your time!
\arrayrulecolor{lightgray}\\toprule[4pt] But this works: \toprule[4pt, lightgray] The other issues should now be fixed.
Click on Details for .Rmd code and screenshot: remotes::install_github("vincentarelbundock/kableExtra@tabularray") ---
output: pdf_document
---
```{r}
library(kableExtra)
kbl(mtcars[1:5, 1:4],
tabular = "tblr",
booktabs = TRUE,
vline = "",
linesep = "\\midrule[2pt, lightgray]",
toprule = "\\midrule[4pt, orange]",
midrule = "\\midrule[3pt, lightgray]",
bottomrule = "\\midrule[5pt, orange]"
)
```
```{r}
kbl(mtcars[1:4, 1:5], tabular = "tblr", align = "c", booktabs = TRUE) |>
add_header_above(
c(" " = 1, "$\\alpha$" = 2, "$\\beta$" = 3),
escape = FALSE) |>
add_header_above(
c( "First Three" = 3, " " = 1, "Penultimate" = 1, " " = 1),
italic = TRUE)
```
|
I think I've come to the conclusion that this is not possible or desirable within |
I propose to add support for tabularray. Using that package, I should be able to bring us to feature parity, while solving all the issues above (and maybe more). Another benefit is that our LaTeX code would be much cleaner and readable, because tabularray allows us to fix global settings for whole rows and columns, instead of having to modify each cell.
border_right
andborder_left
add_header_above()
argumentsscale_down
longtblr
sometimes leaves a single row with an empty page. weird line breakskable_styling(position = "center")
cell_spec()
, but I'm not sure there's a good path forward here.tabularray
should not support vectorized arguments inrow_spec()
andcolumn_spec()
, because this goes against the fundamental package design, which treats rows and columns as "blocks" with separate settings, instead of applying styles to individual cells. We should return an informative error or warning.Problem
We use the
tabu
LaTeX package forfull_width
andbackground
. Unfortunately,tabu
is unmaintained, it has not been updated for 10 years (except an emergency patch), and it has major bugs and limitations (ex: dealing with conflicts of colors). We hit those limitations often, as attested by all the Github Issues related to striping androw_spec
/column_spec
/cell_spec
.After playing around with this for many hours, I've come to the conclusion that many
kableExtra
bugs will be very hard --- or more likely impossible --- to fix withtabu
. Take these, for example:linesep
isn't applied in correct colors to striped booktabs LaTeX tables #616Implementation
To use
tabularray
, the user needs to explicity specify thetabular="tblr"
argument inkbl()
. If this argument is not specified, everything works exactly as before. If the argument is supplied explicitly, we bypass the defaultrow_spec_latex()
/column_spec_latex()
/cell_spec_latex()
functions and use the analogues stored in theR/tabularray.R
file instead.Accordingly, this PR should zero effect on current functionality and should essentially not be a breaking change (unless someone already used that specific argument, in which case all other functions would not work anyway).
Long run
In the long run, I think that
tabu
should be deprecated completely, because it is fundamentally unsuited forkableExtra
's needs, which leads to poor user experience in some cases. But that is a discussion that we can obviously have much later, whentabularray
(or some other solution) has proven itself.Working example (code and screenshot below)
Install my branch:
Then, render this Rmarkdown document: