Runestone page template

[ascholerChemeketa]

This adds logic to build a file that RS can use as a Jinja template for student facing pages so they better match the book they are generated for.

Currently just looking for a review of the XSL. Biggest yuck is the need to pass b-runestone-pagetemplate through file-wrap to the helper templates. We don't want the extra content on every page for a runestone book, so we can't just switch on b-host-runestone. We need to know that this specifically is the template page.

Maybe the template generation should be an additional conversion? A simple template that pretext.py runs directly on the source as an extra step when building for runestone?

[rbeezer]

Claude likes it, and so do I. Planning to merge, review coming just for the record.

Note: Claude assumed pretext-runestone.xsl imported pretext-html.xsl (not true!) and had a whole lot of hesitations... (I spared you all that.)

[rbeezer]

Reviewed the XSL, and built both paths to check it: the sample article as plain HTML (non-Runestone) to confirm nothing else moved, and the sample book (no-parts) with publication-runestone-academy.xml to exercise the new feature itself.

• Plain HTML: output identical to master apart from timestamps — the latex-macros and file-wrap refactors are output-neutral for ordinary builds.
• Runestone build: produces _base.html correctly — {% block title/content/css/js %}, the {% raw %}…{% endraw %} macro wrapper, the literal <base href="{{base_url}}">, the ptx-runestone-template body class, and the footer.html include all land as intended.

latex-macros named-template → mode conversion — clean. Every call-template name="latex-macros" moved to apply-templates select="." mode="latex-macros" across html, basic-html, jupyter, revealjs, and smc, with the per-converter definitions (html, jupyter) moved to mode too. No orphaned call sites; import precedence preserves the jupyter override. The payoff — the extraction stylesheet wrapping macros in {% raw %}…{% endraw %} via apply-imports — justifies it, and it works.

file-wrap extension hooks — good seam. The four file-wrap-{head-pre,head-post,body-attr-extra,body-post} modes with empty match="*" defaults, plus title and b-include-bottom-nav, are clean and demonstrably zero-impact for existing builds. This reads much better than threading a b-runestone-pagetemplate boolean — and you landed on the same conclusion, since the current commits drop the flag in favor of these hooks plus the dedicated extract-runestone-page-template.xsl conversion run from pretext.py. That separate-conversion route is the right call: the template is a distinct output artifact, not a variant page. The brace handling is correct and deliberate too — <xsl:attribute name="href">{{base_url}}</xsl:attribute> to keep a literal {{ (an AVT would collapse it).

canonical-link refactor — fine. Sourcing site-root from runestone-server-baseurl (honoring an authored @baseurl) under the $b-host-runestone guard is a clean improvement over the hard-coded URL and clears the stale TODO.

Smaller notes:

• host-platform / b-host-runestone come from publisher-variables.xsl, so the new report-publisher-variables.xsl line and the extraction guard are well-grounded.
• The extraction stylesheet redefines $rso/$rsc as {{/}}, but it imports pretext-html.xsl (not pretext-runestone.xsl, where ~._ lives), so those overrides may be inert here — harmless, just possibly unnecessary; worth a glance.
• b-include-bottom-nav cleanly gates the whole ptx-content-footer — correct for a template page.

Net: the XSL is in good shape and the feature works on the Runestone target. No blocking change.

Claude Opus 4.8, acting as a review assistant for Rob Beezer

[rbeezer]

I guess the "more standard" delimiters {{...}} are the right thing for the reader-facing pages this will be used for.

[rbeezer]

Merged as-is, plus CSS update. Starting to feel like file-wrap needs a refactor, but I'm not sure what that would be...