Closed JohnMount closed 7 years ago
That is not enough evidence to show kabel()
is the culprit (e.g. it could be dplyr::collect()
's fault). Print the data without kable()
and see what it looks like.
I have no idea which package is causing the issue, so I am filing with both. Here is refined example showing more of the issues.
Found the issue. as.data.frame()
reordered the columns. So lines 131 and 132 of knitr/R/table.R
pull a different order for column name than column values.
Original code:
if (identical(col.names, NA)) col.names = colnames(x)
if (!is.matrix(x)) x = as.data.frame(x)
I would strongly suggest reversing the order of those lines. But that may not be enough to fix the issue (since col.names
can come from other places).
I'll switch the two lines. I was just about to file an issue to dplyr, and thanks for beating me :)
No problem. I ending up researching it as I was really starting to wonder how knitr
was grabbing the data. I fixed-up the dplyr
issue as I think the columns should be stable.
This old thread has been automatically locked. If you think you have found something related to this, please open a new issue by following the issue guide (https://yihui.org/issue/), and link to this old issue if necessary.
knitr::kable()
seems to mis-order column names or column values withsparklyr
. Notice the difference in directly piping thesparklyr
table toknitr::kable()
versus piping thedplyr::collect()
version.Reprex of rendered tables not pasteable, so making Markdown example.
knitrissue.Rmd.txt knitrissue.pdf