Html toc single build#2335
Conversation
|
That is brilliant! Cleaner code, no-change diffs, and a speed-up. (And a nice sequence of commits.) Will update website shortly, a few more PRs to do. Keep 'em coming! |
|
Uh-oh.... this seems to have broken revealjs builds. I get a lot of: starting at the commit that these were merged. |
|
It looks like it still generates the show correctly, but it does produce those scary-looking messages. They all come from where the ToC is being built into a variable. The quick and dirty fix is to add a variable that pretext-revealjs.xsl sets and pretext-html checks while building the ToC. That may be part of the right fix as well - there is no reason that pretext-revealjs.xsl needs the ToC generated. It does feel a little ugly to have the more generic sheet (pretext-html) rely on hints from the most specific sheet, but that may be unavoidable. It does feel like there is a bigger issue here. Shouldn't we be able to provide the answer to "is-leaf" and "level" for "frontmatter" in a slideshow? If that was fixed the bug reports would go away. That seems like it has implications for #2334 |
|
Reviewed the PR and the RevealJs stylesheet. Not seeing it.
Might just be a matter of defining a level for I'll get back to this in a bit, when I am able. |
So we override the |
|
Fix in at: 2fb780c Thanks @oscarlevin for the heads-up and @ascholerChemeketa for the hints. |
|
Can confirm that the most recent commit fixed the issue. Thanks! |
The ToC is a significant chunk of each HTML page and is mostly the same on every page. This PR precomputes the ToC into a variable and then on each page augments that with the necessary
activeandcontains-activeclasses.Reduces xsltproc time by ~15-20% for sample book. For books with lots of smaller pages savings can be 35%+.
Clean diffs on sample book.