yihui / knitr

A general-purpose tool for dynamic report generation in R
https://yihui.org/knitr/
2.37k stars 872 forks source link

Hook for "table caption position" option, similar to `fig.topcaption` #1995

Open DaniMori opened 3 years ago

DaniMori commented 3 years ago

It would be interesting to be able to modify the table caption position from "top" to "bottom", similarly to what fig.topcation=TRUE does for caption figures to allow putting them on top of the figure.

The implementation may be something like

```{r tab.bottomcaption=TRUE}```

or

```{r tab.topcaption=FALSE}```
cderv commented 3 years ago

This is a duplicate of https://github.com/yihui/knitr/issues/1189 - See discussion there and comments like https://github.com/yihui/knitr/issues/1189#issuecomment-266144845

I assume here you are talking of kable() which is in knitr. You can already change the caption position if you use another Table making package like gt (https://gt.rstudio.com/index.html) or flextable (https://davidgohel.github.io/flextable/index.html), or kabelExtra.

You'll see in both those examples that Tables title are often in header and footnotes is used at the bottom sometimes.

cderv commented 3 years ago

Duplicate of #1189

cderv commented 3 years ago

@yihui I set the label to indicate that this would be maybe considered if someone make a PR for this. Otherwise, there is little chance that we would modify the way kable() is working. I let you do otherwise if you prefer. Thanks.

DaniMori commented 3 years ago

Well, I would not regard this as a kable feature, but rather as a chunk option that could be set individually for each chunk in its header or through opts_chunk$set() for all chunks, regardless of whether the output is a kable or not. Actually, this would be the ideal, as it's probably not uncommon that someone wants to set all the table captions to be at the bottom for a whole document.

I'm sorry that I overlooked issue #1189 (I really tried to look for something about caption position but maybe I looked for "table" and that's why I didn't get results about kable). Nevertheless, if you consider what I say about chunk options, I think it shouldn't be regarded as a duplicate.

cderv commented 3 years ago

I feel that the caption setting and handling will be very different depending on the Table 📦 used in the chunk. I don't think it is like figure which share a common syntax for inclusion and for which knitr handles the insertion when a plot is creation - hence the fig.cap chunk option that you can set in a chunk.

For Table, i see it as a bit different. The Table code is not created by knitr directly - the code is created by the package used in R to print the dataframe during knit process. This is surely why there is no tab.cap chunk option because knitr alone can't know how to insert a table caption for all type of table. Usually caption is set directly in the table function (like kable()) and sometimes it will be differently done depending on the output format (Markdown Table, HTML table, LaTeX table).

And regarding Markdown table, even Pandoc does not allow us to choose where the caption is position I believe: https://pandoc.org/MANUAL.html#tables

That is why, from knitr point of view, this FR would concern kable() only - as a chunk option, global or not. knitr alone can't add a chunk option that would work with all type of table you could find. The other package author would have to support this chunk option in there knit print method - which they can already. This is also why this kind of feature is more suited to be inside each extension package that in knitr codebase directly.

Does this clarify my first comment ?

I am happy to discuss any idea you have on this, and also feel free to suggest your ideas as a PR - we'll be happy to review to consider it as part of knitr.

DaniMori commented 3 years ago

Thanks @cderv, I think this clarifies the issue completely. IMO, there is no use in discussing it further or trying a PR given what you say. I'd say then that this issue should probably be closed instead of marked as duplicate. Thanks for discussing it though, at least it helped me gain a better understanding of the knitr and markdown underpinnings :)

yihui commented 3 years ago

To implement this one, we would have to implement #1189 first, which is probably not too hard if we only consider the kable() function (I'm just not highly motivated to do it). It will be trickier to provide a global chunk option like tab.topcaption because it will need other table packages' support.

If #1189 is implemented someday, I'd be happy to provide a global option like options(knitr.kable.topcaption = FALSE) to move kable() captions to the bottom by default.

ajcanepa commented 2 months ago

To implement this one, we would have to implement #1189 first, which is probably not too hard if we only consider the kable() function (I'm just not highly motivated to do it). It will be trickier to provide a global chunk option like tab.topcaption because it will need other table packages' support.

If #1189 is implemented someday, I'd be happy to provide a global option like options(knitr.kable.topcaption = FALSE) to move kable() captions to the bottom by default.

Dear @yihui, Is this implementation already present? In scientific writing (and elsewere) the tables caption goes in the lower part of the table, this is an standard. Thus, will be great to be able con change the table's caption position.

yihui commented 2 months ago

@ajcanepa Not yet. Sorry.

BTW, in litedown (a complete rewrite of knitr and R Markdown), the chunk option cap.pos (= 'top' or 'bottom') controls the position of captions for both tables and figures.

ajcanepa commented 1 month ago

@ajcanepa Not yet. Sorry.

BTW, in litedown (a complete rewrite of knitr and R Markdown), the chunk option cap.pos (= 'top' or 'bottom') controls the position of captions for both tables and figures.

Thanks, @yihui . I'll have to take a look at litedown. Sometimes is difficult to keep the pace to all this new development. I hope the change to a "new" version is better than the improvement to the old version, good luck on this!

DaniMori commented 1 month ago

Just so we know, please: Is litedown going to substitute both the rmarkdown and knitr packages, somehow? And if so, can you tell if the rendering engine in Quarto will change from knitr to litedown?

Thanks!

cderv commented 1 month ago

can you tell if the rendering engine in Quarto will change from knitr to litedown?

litedown works quite differently from rmarkdown as it won't use Pandoc to produce document, and no even knitr for evaluation. It is also targetting HTML output mainly. The website is really a interesting read: https://yihui.org/litedown/ The first Caution box there is the following

Besides, litedown was designed for minimalists with a limited scope. Average users should perhaps consider using rmarkdown or Quarto instead.

So I can say that litedown can't be used in Quarto, and Quarto will continue to use knitr and rmarkdown for the computation engine involving R computations. There won't be changes to this. Quarto is broader scope that litedown.

FWIW Quarto has also improved feature over rmarkdown and knitr like setting the caption position.

litedown is an alternative made as 'a complete rewrite' as @yihui mentioned. I'll let give more context about it.

yihui commented 1 month ago

litedown will never substitute knitr or rmarkdown, and I think it's very unlikely that Quarto will use litedown someday. Personally I have no expectation on litedown to become popular or widely used.

That said, I've definitely been more thoughtful when designing litedown since I can learn from the experience of 12 years, and some knitr/rmarkdown problems have become much easier to solve in litedown (such as this caption position issue).

DaniMori commented 1 month ago

Thanks a lot to both of you for the feedback.

I had noticed the improvement in Quarto, which is great and solves the issue in most use cases, for me at least.

Although being a little offtopic, let me say that Quarto has done an amazing work making publishing easy for everyone (that don't have "motivational" barriers). The only thing I miss in Quarto is making it easy to switch to landscape-mode pages halfway through the document (e.g. to insert a table). Once that is sorted out, it's likely that I never have to use "plain rmarkdown" again 😁

yihui commented 1 month ago

The only thing I miss in Quarto is making it easy to switch to landscape-mode pages halfway through the document (e.g. to insert a table).

@DaniMori If you print HTML to PDF, that problem can be solved by two lines of CSS.

@page landscape { size: landscape; }
.landscape { page: landscape; }

Example (with litedown, but the idea works for any package):

---
title: "Landscape Table"
output: litedown::html_format
knit: litedown:::knit
---

```{css, echo=FALSE}
@page landscape { size: landscape; }
.landscape { page: landscape; }

A portrait table.

mtcars
head(iris)[, rep(1:5, 2)]

A portrait table again.

iris


Output: [Landscape Table.pdf](https://github.com/user-attachments/files/16102444/Landscape.Table.pdf)