Why it's not parsed yet

Paged is a layout renderer: it reads the layout view and never walks the tagged-XML tree, so a document renders identically with or without XML tags.

In short: The structured-content layer is a real part of every IDML package, yet the Paged renderer ignores it. Paged turns documents into pages, and everything it needs lives in the layout view — spreads, stories, and styles — not in the tagged-XML tree, which organizes the same content by meaning rather than position. This page explains why that is true, points at the two exact places in the parser where the layer is skipped, and sketches what supporting it would take. It describes a deliberate scoping decision, not a bug — and a format the renderer does not act on today.

The structured-content layer is a real part of every IDML package, and yet the Paged renderer produces the same pages whether or not a document carries any XML tags. This page explains why that is true, and points at the exact places in the parser where the layer stops at the door.

The renderer reads layout, not structure

Paged is a layout renderer. Its job is to turn a document into pages, and the information it needs for that lives entirely in the layout view: spreads place frames, frames pull text from stories, and styles decide how the text is set. The tagged-XML layer is a second view of the same content, organised by meaning rather than by position. Nothing in it changes where a glyph lands on a page.

So the parser follows the layout view and only the layout view. It opens the container, confirms the IDML mimetype, reads designmap.xml, and from there walks to the spreads, master spreads, stories, and resource parts it needs. The backing story, the tag list, and the style-mapping table are simply not on that path.

Where the layer is skipped

There are two concrete places in the engine where the tagged-XML layer is present but goes unread.

The design map drops the backing-story reference. A package's design map lists XML/BackingStory.xml through an idPkg:BackingStory element, exactly as it lists spreads and stories (see the design map). The design-map parser matches only the references it acts on — idPkg:Spread, idPkg:Story, idPkg:MasterSpread — and a catch-all arm silently ignores everything else, idPkg:BackingStory included. So the pointer to the backing story is read past and discarded before anything could follow it.

Not yet parsedcore/crates/paged-parse/src/designmap.rs — idPkg:BackingStory falls through the match's catch-all arm

Nothing parses the XML/ tree. When the container is opened, every entry in the archive is decompressed into an in-memory map, so the bytes of XML/BackingStory.xml, XML/Tags.xml, and XML/Mapping.xml are available. But the parser only ever turns one entry — designmap.xml — into a typed tree; the rest are kept as raw bytes for the higher layers to pull on demand, and no layer asks for the XML/ parts. There is no XMLElement, XMLStory, XMLTag, or mapping reader anywhere in the crate to ask with.

Not yet parsedcore/crates/paged-parse/src/lib.rs — Container::open decompresses all entries but parses only designmap.xml

Because the bytes are retained, supporting the layer later is purely additive: a new reader could be pointed at the already-present XML/ entries without changing how the container is opened.

What supporting it would take

Reading the layer is not the hard part — the work is deciding what a layout renderer should do with structure that does not affect layout. A first pass would look roughly like this:

1. Follow the reference. Give the design-map parser an arm for idPkg:BackingStory so the pointer to XML/BackingStory.xml is captured instead of dropped.
2. Parse three new parts. Add readers for the <XMLStory> / <XMLElement> tree in BackingStory.xml, the <XMLTag> list in Tags.xml, and the <XMLExportMap> / <XMLImportMap> entries in Mapping.xml, producing typed structures the way the existing story and style readers do.
3. Resolve the cross-references. Tie each <XMLElement>'s XMLContent back to the layout item it labels (a Story, Rectangle, or TextFrame), and each MarkupTag back to its <XMLTag>. This is where tagged-but-unplaced content in the backing story would need a home.
4. Decide the consumer. Surface the resolved tree to something that wants it. This is structured data, not pixels, so the natural consumer is introspection or round-tripping, not the page rasteriser — the renderer would keep producing the same pages.

Until those steps exist, the chapter stays honest about its status: the format is documented in full, and the renderer reads none of it.

Frequently asked questions

Why doesn't Paged parse the tagged-XML layer? Because nothing in it affects layout. Paged turns a document into pages, and the position of every glyph and frame is decided entirely by the layout view — spreads, stories, and styles. The tagged-XML tree is a second view organized by meaning, so skipping it is a deliberate scoping decision, not a bug.

Where in the parser is the layer skipped? In two places. The design-map parser matches only the references it acts on (idPkg:Spread, idPkg:Story, idPkg:MasterSpread) and lets idPkg:BackingStory fall through its catch-all arm; and although Container::open decompresses every archive entry into memory, only designmap.xml is turned into a typed tree, so the XML/ parts are never read. Both spots carry a Not yet parsed badge above.

Will tagged XML ever be supported? It is not on a committed timeline here. Because the bytes are already retained in memory, adding support would be purely additive — but the open question is what a layout renderer should do with structure that does not affect layout, which points toward introspection or round-tripping rather than the page rasteriser.

Does ignoring the layer ever change the rendered pages? No. A document renders identically whether or not it carries any XML tags, since the renderer never reads the backing story, the tag list, or the mapping table.