A chapter boundary should be traceable from a precise source location to a precise output document. Blank lines and screen wrapping are not enough. In the STUDIO-273 fixture, one EPUB page break marker was inserted before a named anchor on source line two, then the exported package was opened to determine what Rune actually generated.
The decisive structural observation is not a literal CSS page-break token. The anchor became the title and h1 of p002.xhtml, and both NAV and NCX link to it. That proves a generated chapter split for this synthetic source. It does not prove where a physical or software reader will draw a visible page boundary.
Choose an anchor before inserting the marker
The starting file contains three lines. Line one is # Chapter Start Boundary 273, line two is CHAPTER-START-ANCHOR-273, and line three is a short paragraph. The requested insertion line was two, so the anchor identifies the first content that should appear after the boundary.
Record the source path and digest before changing it. An anchor is more reliable than “the second line” after later edits because added headings or blank lines can shift numeric positions. The acceptance card stores both: requested line two and the exact anchor string.
The marker is tested on synthetic text, not the only copy of a manuscript. A production run should use a duplicate and give every intended chapter start a unique phrase that can be found in source, navigation, and XHTML.
Preview and save exactly one source marker
The operation first ran as a dry run, then applied one marker at line two. Both commands exited successfully. The saved source contained one 《《｜Page Break｜》》 marker immediately before CHAPTER-START-ANCHOR-273, and a source reinspection also completed successfully.
One saved marker is an input receipt, not an output guarantee. It proves that the requested notation reached the source file. It does not tell us whether export split a document, emitted a CSS rule, ignored the marker, or leaked the literal notation into the book.
Failure at this stage includes zero markers, more than one marker, insertion after the anchor, or a marker placed in the middle of the heading text. Recovery returns to the original source digest and repeats the dry run with the anchor visible in the preview.
Understand why no page-break token appears
The exported XML and CSS were searched for page-break, break-before, break-after, and pagebreak. Every literal token count was zero. The source marker itself also leaked zero times into the generated package.
That absence does not by itself mean the operation failed. Rune converted the marker into a document boundary: the anchor begins a separate generated XHTML file. Looking only for a CSS property would miss that transformation. Conversely, seeing zero literal markers is not enough to claim success; the new document and its routes must be inspected.
This distinction is important when diagnosing another project. An exporter may represent an authored boundary by splitting XHTML, by applying CSS, or through another documented structure. Review the output actually produced rather than demanding one implementation pattern.
Verify the opening of p002 and both navigation maps
The measured EPUB is studio-273-measured.epub, with SHA-256 c822ebc225b5994c1c5f437ece36307c5d0081b771dbf9ee4d18d3d3b2663af1. Local inspection returned valid=true. In OEBPS/Text/p002.xhtml, CHAPTER-START-ANCHOR-273 appears twice: once in the document title and once as the chapter h1. The following paragraph also appears inside the same section.
nav.xhtml contains the anchor once and links to p002.xhtml. toc.ncx contains the anchor once and points to Text/p002.xhtml. All three routes identify the same generated chapter opening. The saved source marker count is one, while literal marker leakage into XHTML is zero.
Acceptance for the structural boundary is therefore a chain: requested line two, one saved marker before the anchor, successful reinspection, the anchor as title and h1 in p002.xhtml, one NAV route, one NCX route, and no literal notation in the publication.
Diagnose an orphaned or misplaced heading
A risky placement puts the marker after a chapter heading. Depending on the source, that can leave the intended heading in the previous generated document and promote an ordinary sentence to the next title. A count of one marker would still pass, but the resulting chapter structure would be wrong.
Detect this failure by reading the first meaningful elements of the generated XHTML, not just searching for the anchor anywhere in the ZIP. The expected anchor belongs in both <title> and <h1> of p002.xhtml. Then verify that NAV and NCX use the same label and target.
If the anchor lands in a paragraph or a different p00N.xhtml, preserve the rejected EPUB, restore the source copy, move the marker before the intended heading or anchor, and export under a new name. Do not move elements inside the generated XHTML by hand; that would leave the source-to-output rule unresolved.
Recheck the whole route after recovery
A corrected insertion earns a new source digest and a new EPUB digest. Repeat the marker count, source readback, XHTML inspection, NAV route, NCX route, and literal-leak search. Checking only the repaired heading could overlook a changed table of contents or a duplicate marker elsewhere.
The recovery receipt should explain why the old artifact failed and why the new one passes. It lists the source anchor, requested line, command results, saved marker count, generated file, title and heading occurrences, navigation routes, and local validation result.
This process is deliberately narrower than a claim that every page break in a full novel works. Apply the same card to each intended boundary and keep results under the digest of the complete export.
Measure visible pagination in named readers separately
The fixed evidence verifies a structural chapter opening in the package. It did not open a physical reader or establish the exact screen on which a page turn occurs. Reader engines may paginate according to viewport, font size, writing mode, margins, and their own handling of document boundaries.
For a release test, load this exact EPUB digest in each target reader. Navigate to the anchor from its contents interface, inspect whether it starts at the expected visual boundary, and record device, application version, orientation, and typography settings. That reader observation is a separate observation field, not a conclusion inferred from p002.xhtml.
The W3C EPUB 3.3 specification defines package and content-document structures, while Rune Studio’s current workflow is described on the official product site. By keeping source notation, generated structure, and visible pagination in separate layers, an editor can locate a failure without overstating what the fixed package proved.