Sections and numbering
How the resolved Page.Name attribute drives the displayed page number in IDML, what the unparsed Section element would add, and the naive fallback when no name is present.
In IDML the displayed page number is already resolved into each page's Name attribute, so the renderer trusts that label and never reads the Section element that produced it.
In short: In InDesign, sections decide what a page is called — a section
breaks the page range into runs with their own start number, numbering style, and
prefix, turning a raw count into labels like "iv" or "B-3". But the IDML a reader
opens does not require re-running that logic: InDesign bakes the resolved label onto
every page as a Name attribute. Our renderer reads Page.Name and substitutes it
wherever an auto-page-number marker appears, which is how it produces correct Roman
numerals and prefixes without implementing a numbering engine. The Section element
that defines those rules is therefore not parsed, and the only consequence is that a
page missing Name — rare outside synthetic fixtures — falls back to naive 1-based
counting. This page explains how Page.Name drives the number, what Section would
otherwise contribute, and what happens when the label is missing.
When a footer prints "page iv" or a cross-reference says "see page B-3", something
had to decide that the page is called "iv" or "B-3" rather than "4" or "27". In
InDesign that decision belongs to sections — a section breaks the page range into
runs with their own start number, numbering style, and prefix. But the IDML a reader
opens does not make the reader re-run that logic. The label is already computed and
written onto each page. This page explains how our renderer uses that, what the
Section element would otherwise contribute, and what happens when the label is
missing.
The displayed number is Page.Name
Every Page element in a spread carries a Name attribute, and that name is the
page's user-visible label — InDesign has already applied the section's numbering
style and prefix when it wrote the file. A plain Arabic page is Name="1"; a
front-matter page is Name="iv"; a prefixed appendix page is Name="B-3". The
renderer reads Name from each page and stores it as that page's label
(paged-parse/src/spread.rs:266, consumed at paged-renderer/src/pipeline.rs:615).
This is why we can produce correct Roman numerals and prefixes without implementing a numbering engine: the answer is a fact in the file, not a computation we have to reproduce.
| Attribute · Page (in a spread) | Type / values | Support | Notes |
|---|---|---|---|
| Name | string | Supported | The displayed page label, with section numbering style + prefix already applied by InDesign. Drives auto-page-number output. |
| Self | string id | Supported | The page id; PageStart on a Section would reference this, if Section were parsed. |
Auto-page-number markers resolve to the label
A footer that prints "the current page number" does not store a literal digit —
InDesign writes a marker into the text, and the marker resolves at render time to
wherever the frame lands. Our parser turns those markers into private-use
placeholder characters; the renderer then replaces each placeholder with the page's
label from the table above (paged-renderer/src/pipeline.rs:3094). For the
current page it uses that page's Name; for the next-page marker it reads the
following page's Name, falling back to a numeric increment of the current label
when there is no next page.
Because the substitution pulls from the same Page.Name labels, a baked Roman or
prefixed label flows straight into the footer — "page iv" comes out as "page iv". The
parser-side mechanics of those markers (the <?ACE 18?> / <?ACE 19?> processing
instructions and their U+E018 / U+E019 placeholders) are documented once in
stories & text → text variables.
The Section element — not parsed
Section is the element that defines the numbering rules: where a numbering run
starts, in what style, with what prefix, and whether it continues the previous
section's count. Its attributes name a starting number (PageNumberStart, 1 to
999999), a numbering style (PageNumberStyle, with values such as Arabic,
UpperRoman, LowerRoman, UpperLetters, LowerLetters, and Kanji), a prefix
(SectionPrefix) and whether to show it (IncludeSectionPrefix), whether to
continue the prior section (ContinueNumbering), and the page the section starts on
(PageStart, referencing a Page Self).
Our parser does not read any of it. We never need those rules, because the output
of applying them — the per-page label — is already present as Page.Name. Parsing
Section would only matter if we wanted to recompute labels rather than trust the
baked ones, which we currently do not.
The practical consequence is narrow: as long as Page.Name is present — which it is
in every real InDesign export — sections are invisible to us in the right way,
because their effect is already in the names.
The naive fallback
When a page has no Name attribute, the renderer cannot trust a label, so it falls
back to a plain 1-based count: the page's position in the document, plus one
(paged-renderer/src/pipeline.rs:615). This fallback has no section awareness — it
cannot produce Roman numerals, restarts, or prefixes, because the information that
would drive them lives in the unparsed Section element. In practice this only
surfaces with synthetic packages and hand-written fixtures that omit Name; real
exports always carry it.
Summary
Page.Nameis the source of truth for the displayed number; the renderer trusts it and substitutes it into auto-page-number markers.Sectionis not parsed — its rules are unnecessary whilePage.Namealready carries the resolved label.- Without
Page.Name, numbering degrades to naive 1-based counting with no Roman, restart, or prefix support.
For where page-number variables come from in the text, and the markers that get substituted, see text variables and stories & text → text variables.
Frequently asked questions
Where does the displayed page number come from in IDML?
It comes from each Page element's Name attribute. InDesign applies the section's
numbering style and prefix when it exports, so Name is already the user-visible
label — "1", "iv", or "B-3" — and the renderer uses it directly.
Does the renderer parse the Section element?
No. Section defines the numbering rules — start number, style, prefix, whether to
continue the previous count — but the renderer never reads them, because the output
of applying those rules is already present as Page.Name. Parsing Section would
only matter if we wanted to recompute labels instead of trusting the baked ones.
How does an auto-page-number marker become an actual number?
The parser turns the marker into a private-use placeholder character, and the renderer
replaces that placeholder with the page's Name label. For the current page it uses
that page's Name; for the next-page marker it reads the following page's Name,
falling back to a numeric increment when there is no next page.
What happens if a page has no Name attribute?
The renderer falls back to a plain 1-based count — the page's position in the
document, plus one — with no section awareness, so it cannot produce Roman numerals,
restarts, or prefixes. This only surfaces with synthetic packages and hand-written
fixtures; real InDesign exports always carry Name.
Text variables
The document-level TextVariable definition in IDML, its VariableType kinds, and the frozen ResultText each TextVariableInstance carries.
Conditional text
Conditional text lets one IDML document carry several versions of its words, with runs shown or hidden depending on whether a named condition is visible.