Check and adapt to new --number-sections in Pandoc 3.1.12

[cderv]

Changed in 3.1.12 https://pandoc.org/releases.html#pandoc-3.1.12-2024-02-14

--number-sections now uses the first digit for the number of the top-level section, no matter what its level. So if the top-level section is level-2, numbers will be 1, 2, etc. rather than 0.1, 0.2, as in the past (#5071). For some backwards compatibility, we revert to the old behavior when the --number-offset option is used.

This makes some of our test to fails

══ Failed tests ════════════════════════════════════════════════════════════════
── Failure ('test-gitbook.R:17:3'): gitbook_toc correctly process pandoc html without anchor section ──
xml2::xml_text(H2) (`actual`) not equal to c("1.1 CHAP1", "1.2 CHAP2") (`expected`).

`actual`:   "1.1 CHAP1" "2.1 CHAP2"
`expected`: "1.1 CHAP1" "1.2 CHAP2"
── Failure ('test-gitbook.R:36:3'): gitbook_toc correctly process pandoc html with anchor section ──
xml2::xml_text(H2) (`actual`) not equal to c("1.1 CHAP1", "1.2 CHAP2") (`expected`).

`actual`:   "1.1 CHAP1" "2.1 CHAP2"
`expected`: "1.1 CHAP1" "1.2 CHAP2"
── Failure ('test-html.R:12:3'): PART feature correctly works in HTML without anchor sections ──
xml2::xml_text(TOC) (`actual`) not equal to c("I T1", "1 CHAP1", "T2", "2 CHAP2") (`expected`).

`actual`:   "I T1" "2 CHAP1" "T2" "4 CHAP2"
`expected`: "I T1" "1 CHAP1" "T2" "2 CHAP2"
── Failure ('test-html.R:26:3'): PART feature correctly works in HTML with anchor sections ──
xml2::xml_text(TOC) (`actual`) not equal to c("I T1", "1 CHAP1", "T2", "2 CHAP2") (`expected`).

`actual`:   "I T1" "2 CHAP1" "T2" "4 CHAP2"
`expected`: "I T1" "1 CHAP1" "T2" "2 CHAP2"

[ FAIL 4 | WARN 0 | SKIP 0 | PASS 108 ]

We need to adapt, and check if this is a problem forbookdown. It is possible the numbering gets modified... 🤔

[cderv]

Regarding the change:

This is due to a Pandoc breaking change (probably this commit

Now when --number-sections, unnumbered title are non-numbered, but the increment the counter.

Here is a simple test showing this

pandoc::pandoc_convert(
  version = "3.1.11.1",
  text = c(
    "# One {-}",
    "",
    "# Two"
  ),
  to = "html",
  args = "--number-sections"
)
#> <h1 class="unnumbered" id="one">One</h1>
#> <h1 data-number="1" id="two"><span
#> class="header-section-number">1</span> Two</h1>

pandoc::pandoc_convert(
  version = "3.1.12",
  text = c(
    "# One {-}",
    "",
    "# Two"
  ),
  to = "html",
  args = "--number-sections"
)
#> <h1 class="unnumbered" id="one">One</h1>
#> <h1 data-number="2" id="two"><span
#> class="header-section-number">2</span> Two</h1>

The second header is now numbered two, and not 1, while the fist is just unnumbered.

@yihui I plan to ask the question on Pandoc's community if this is really expecting change - it is quite suprising to me, and this may require us to process the headers and renumber everything - or leverage new pandoc's feature (chunked HTML for example)

This is quite an important breaking change for us.

Edit: asked at jgm/pandoc#9513

[yihui]

Thanks for reporting the issue to Pandoc! Since this has been confirmed as a Pandoc bug, I think we just need to wait for the upstream fix (I feel this would be too much trouble for us to fix on our side).

[cderv]

Yes issue is now at

• New --number-sections behavior from 3.1.12 increments counter in numbering even when .unnumbered class is used jgm/pandoc#9516

I am glad this has been confirmed as a bug because it would have been really heavy work to try adapt and fix this. 😅

[cderv]

This is solved in Pandoc and test on Nighthly version is now passing. So it will resolve itself when new Pandoc version is out.
https://github.com/rstudio/bookdown/actions/runs/8094450051/job/22119169746

[cderv]

Pandoc 3.1.12.2 has been released https://github.com/jgm/pandoc/releases/tag/3.1.12.2

[github-actions]

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.