Skip to content

HTML: ensure introductions in printout page get correct structure#2847

Closed
oscarlevin wants to merge 1 commit into
PreTeXtBook:masterfrom
oscarlevin:printout-intro
Closed

HTML: ensure introductions in printout page get correct structure#2847
oscarlevin wants to merge 1 commit into
PreTeXtBook:masterfrom
oscarlevin:printout-intro

Conversation

@oscarlevin
Copy link
Copy Markdown
Member

If an author writes a worksheet or handout with an <introduction> but wants that on its own page (like a cover page for an exam), it seems natural to put the introduction in a <page> element. However, the xsl for introduction only places it in an html <section> if the introduction lives inside STRUCTURAL. This simply adds self:page to the filters for structural to get the expected html in this case.

@rbeezer
Copy link
Copy Markdown
Collaborator

rbeezer commented May 12, 2026

I don't think of page as being structural. Those are meant to be the elements that provide the gross structure of the document, for numbering, chunking, etc. So it feels like too much might change if this is added to the filter (and not to the definition entity). I think Claude is of the same mind. That review next. Maybe the "narrow fix" will do the job.

@rbeezer
Copy link
Copy Markdown
Collaborator

rbeezer commented May 12, 2026

Thanks for tracking this down, @oscarlevin. The motivating case (intro inside <page> getting routed to the inline-intro template) does need fixing.

One concern about the lever, though: STRUCTURAL-FILTER is referenced in ~14 places across the XSL, and most of them aren't about intro/conclusion routing — they're about numbering, depth counting, chunking, sibling traversal, and so on. Adding self::page to the entity changes all of them in one step. A few that look most exposed:

  • pretext-common.xsl:4828ancestor::*[&STRUCTURAL-FILTER;][1] is the "nearest structural ancestor" used for numbering. Items inside a <page> will now find the page rather than the worksheet as their numbering context.
  • pretext-html.xsl:1951, :11639, :11738 — depth counts and first/last structural child of a worksheet shift when pages are counted as structural.
  • pretext-json-manifest.xsl:130 and pretext-smc.xsl:102 — pages start to look like chunk roots in manifest and SMC contexts.
  • pretext-jupyter.xsl:406 already special-cases pages with an explicit *[parent::page] alternative next to its STRUCTURAL-FILTER test, which reads to me as an existing signal that pages weren't intended to be structural.

A narrower fix would be to add or self::page to the two specific intro/conclusion predicates in pretext-html.xsl:1177 and the matching exclusion at :5508, leaving the global entity alone. That achieves the stated goal without touching the other eight sites.

If broadening STRUCTURAL-FILTER is the right design call (i.e., <page> really should be promoted to structural), the change is fine — but it would probably be worth a worksheet smoke test that exercises numbering of items inside pages and the HTML TOC for a multi-page worksheet, to confirm nothing shifts unexpectedly.

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

@oscarlevin
Copy link
Copy Markdown
Member Author

That makes perfect sense and was my next best guess. Force pushed with those changes.

@rbeezer
Copy link
Copy Markdown
Collaborator

rbeezer commented May 12, 2026

I've merged this, as-is. But I think there is more work to do.

The sample article had no example testing this change. So the most expedient thing to do was to move the opening page "up" on an example with an introduction. Great for testing and everything works as expected. But bad for the sample article, since that introduction has numbered stuff in it (figures). I really want to clamp down on heavy introductions. ;-) Would you mind making a better example someplace in the sample article? You could start a commit by reverting the one I just pushed. And now that I think about it, that introduction maybe doesn't need to be marked up? A worksheet is not structured further, so it is serving no purpose.

Schema is going to need a "FirstPage" pattern? (Maybe we have one already.) Likely no matter what, if we have objectives? And a "LastPage" pattern?

I'm rambling a bit - maybe this should be a -dev discussion. I'm feeling like introduction should be banned from worksheet?

@rbeezer rbeezer closed this May 12, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants