Pages tool compatibility boundary introduced in Inkscape 1.2 multi-page SVG documents

Inkscape 1.2 introduced a Pages panel that allows a single SVG to contain multiple page frames with individual sizes, orientations, and margins. Because SVG has no native page concept, the feature relies on Inkscape-specific metadata and group structure, creating a compatibility boundary where cross-application rendering behavior is not standardized.

The unresolved design question is whether page boundaries should function as document-level metadata or as clipping groups. This choice affects how stroke widths, filters, and object snapping behave when elements cross page edges. In practice, exporting to PDF maps each page to a PDF page, but other SVG renderers often display all frames stacked or clip to the first page, ignoring the page definitions entirely.

Behavior may also differ across versions, as export options and metadata handling around Pages have evolved since the 1.2 release. Before relying on multi-page SVGs outside Inkscape, it is necessary to determine the intended semantic model for page boundaries and the expected fallback in standard renderers.

Should page boundaries in Inkscape 1.2 and later be treated as document-level metadata or as clipping groups to ensure predictable stroke and filter behavior at page edges? What rendering behavior should be expected when a multi-page SVG is opened in a standard SVG editor or browser that ignores Inkscape page metadata? Do page boundary semantics and export behavior remain consistent across Inkscape 1.2, 1.3, and subsequent releases?