footnotes with locations move out of order

[shannonhaughton]

Prework

• Read and agree to the code of conduct and contributing guidelines.
• If there is already a relevant issue, whether open or closed, comment on the existing thread instead of posting a new issue.

Description

Rather than remaining in the order they were set, footnotes with locations are moved to the bottom of the footnote list.

This happens because when the footnotes are bound back together post processing in resolve_footnotes_styles the location footnotes are added at the bottom. For example here with the column cells:

gt/R/z_utils_render_footnotes.R

Line 274 in 0d3012c

tbl <-

Reproducible example

gt <- gt::exibble |> 
  gt() |> 
  tab_footnote("footnote 1") |> 
  tab_footnote("middle footnote with location",locations = cells_column_labels(columns=fctr)) |> 
  tab_footnote("last footnote")

Expected result

I would expect 'footnote 1' to be at the top, the footnote with the location to remain in the middle and the 'last footnote' to be at the bottom.

Actual result

Session info

R version 4.4.1 (2024-06-14)
Platform: aarch64-apple-darwin20
Running under: macOS 15.6

Matrix products: default
BLAS: /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib
LAPACK: /Library/Frameworks/R.framework/Versions/4.4-arm64/Resources/lib/libRlapack.dylib; LAPACK version 3.12.0

locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8

time zone: Europe/London
tzcode source: internal

attached base packages:
[1] stats graphics grDevices utils datasets methods base

other attached packages:
[1] gt_1.0.0.9000 testthat_3.2.3

loaded via a namespace (and not attached):
[1] sass_0.4.10 generics_0.1.4 xml2_1.3.8
[4] bitops_1.0-9 digest_0.6.37 magrittr_2.0.3
[7] evaluate_1.0.3 RColorBrewer_1.1-3 pkgload_1.4.0
[10] fastmap_1.2.0 rprojroot_2.0.4 pkgbuild_1.4.7
[13] sessioninfo_1.2.3 brio_1.1.5 urlchecker_1.0.1
[16] promises_1.3.2 purrr_1.0.4 scales_1.4.0
[19] cli_3.6.5 shiny_1.10.0 rlang_1.1.6
[22] ellipsis_0.3.2 bigD_0.3.1 commonmark_1.9.5
[25] base64enc_0.1-3 remotes_2.5.0 withr_3.0.2
[28] cachem_1.1.0 devtools_2.4.5 tools_4.4.1
[31] memoise_2.0.1 dplyr_1.1.4 httpuv_1.6.16
[34] vctrs_0.6.5 R6_2.6.1 mime_0.13
[37] lifecycle_1.0.4 juicyjuice_0.1.0 reactable_0.4.4
[40] fs_1.6.6 htmlwidgets_1.6.4 usethis_3.1.0
[43] miniUI_0.1.2 pkgconfig_2.0.3 desc_1.4.3
[46] pillar_1.10.2 later_1.4.2 rsconnect_1.3.4
[49] glue_1.8.0 profvis_0.4.0 Rcpp_1.0.14
[52] xfun_0.52 tibble_3.2.1 tidyselect_1.2.1
[55] knitr_1.50 rstudioapi_0.17.1 farver_2.1.2
[58] xtable_1.8-4 htmltools_0.5.8.1 rmarkdown_2.29
[61] compiler_4.4.1 markdown_2.0

[rich-iannone]

This is by design. The footnotes part of the footer has two separate sections displayed in this order: (1) location-independent (markless) footnotes (in the order provided), (2) location-based (marked) footnotes (with marks in reading/display order).

It's like this is to fit the conventions I've seen elsewhere (can't point to specific examples right now, but when researching I did find this pattern quite often). Doing it the other way (i.e., mixing footnotes of styles (1) and (2)) is also hard because the latter footnotes rearrange to reading order (and don't follow calling order) and markless footnote can also be misconstrued as a part of the preceding marked footnote.

Do you strictly need unmarked footnotes mixed in with the marked footnotes? I think we could enable a workaround somehow.

[shannonhaughton]

We don't necessarily need them all mixed together- that feels off, but in our tables the marked footnotes are typically at the top, with the unmarked underneath. So even an option to switch the order would be really helpful for us

[rich-iannone]

Sorry I didn't respond to this before! Yes, this makes sense now and thanks for the PR.

I'm in the middle of the gt release process so I probably can't get that PR into the release (unless I have to resubmit, then it could be done!). There's actually a few test failures with tfrmt with the gt v1.1.0 release candidate. I'll create an issue on the tfrmt repo that shows the failing testthat tests.

[rich-iannone]

With #2036 now merged (thanks for that PR!), we can now close this issue.