Work in progress — this reference is being written in the open. Unfinished pages are excluded from search engines.
Paged · IDML Reference
Sections, numbering & variables

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.

Intermediate· explanation

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 / valuesSupportNotes
NamestringSupportedThe displayed page label, with section numbering style + prefix already applied by InDesign. Drives auto-page-number output.
Selfstring idSupportedThe 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.

Not yet parsedThe Section element and its numbering rules (PageNumberStart, PageNumberStyle, SectionPrefix, ContinueNumbering, PageStart) are skipped; the renderer trusts Page.Name instead.

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.

Not yet parsedNo-name fallback is naive 1-based numbering with no section awareness — paged-renderer/src/pipeline.rs:615

Summary

  • Page.Name is the source of truth for the displayed number; the renderer trusts it and substitutes it into auto-page-number markers.
  • Section is not parsed — its rules are unnecessary while Page.Name already 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.

On this page