Compatibility

Compatibility is the dividing line between what survives an IDML round trip and what the format hands back to the application to recompute.

In short: A round trip preserves whatever the XML writes down and loses whatever it does not. Structural facts — page and spread geometry, text and its flow order, styles, colors, references — cross intact; results-of-the-moment like resolved text variables and the application's private working state do not. The format's version is data stamped into each package rather than a single dial, and the vocabulary grows additively as the format gains capabilities. Our reader targets one modern DOM and does no version negotiation — an honest limitation this page is precise about.

A round trip preserves whatever the XML writes down and loses whatever it does not. That sounds obvious, but the dividing line is specific, and knowing where it falls is the difference between trusting a generated file and being surprised by it. This page draws the line in two passes: what crosses intact, and what the format hands back to the application to figure out for itself.

What survives

The interchange form is built to let a second tool reconstruct the document, so it keeps the things reconstruction needs: the page and spread geometry, the text and the order it flows in, the styles and how they cascade, the colors and swatches, and the references that bind the parts together. Those are structural facts, written explicitly into the XML, and they make the full trip out and back without loss. The binary-to-XML lineage explains why that boundary exists in the first place: the XML carries the document's structure and intent, deliberately not the source application's runtime memory.

What is left to the application

Some things are recorded as results, not as live instructions, and the format trusts whoever opens the file to refresh them if it cares to. The clearest case is a text variable: the package stores the text the variable resolved to at the moment of export, not a standing order to recompute it per page. The form says "this is what it read then," and recomputation is the reading application's job, not the file's.

The application's private working state is the other half of what does not survive: caches it rebuilds on open, undo history, selection, and editor-only bookkeeping never enter the XML. They are not lost in transit — they were never written down, because they belong to one application's session rather than to the document.

The format's version is data, not a site version

It is tempting to read a version stamp like DOMVersion="20.0" as "the version of the software" — a single dial that everything tracks. It is not that. The format's version is a property of each package: a fact the producer wrote into the file, describing the revision of the format that file follows. Different files in the same workflow can legitimately carry different stamps.

The version is data-shaped in a deeper way, too. When the format gains a capability, it does so by adding new elements and attributes that older files simply do not contain — the container's overall shape stays put while the vocabulary grows. A newer package is mostly an older one plus some extra elements. That is why a reader can often get a long way with a file from a different vintage than it was built for: the parts it knows are still where it expects them, and the parts it does not know are additions it can skip.

There is also a defined story for going backwards between application versions, and notably it does not run through IDML. The interchange form is the forward-and-sideways path; moving a document to an older application generation uses a separate earlier interchange format (INX) rather than IDML. That asymmetry is part of why "version compatibility" is not one knob — it is a set of producer-stamped facts plus the conventions each reader applies to them.

What our reader does — honestly

We do not negotiate on any of it. Our parser targets one modern DOM and reads every package through the same path, whatever version it claims. The version markers are recorded and then read past; none of them changes how the file is parsed. In practice this works because of the additive shape described above — the structure we target is present in the files we care about — but it is a real limitation, and it is worth being precise about its edges.

DOMVersion, featureSet, and readerVersion do not branch behavior. The reader is version-agnostic by construction: it never reads DOMVersion, never decodes the featureSet bitmask, and never compares readerVersion against a supported floor.

Parsed, not yet renderedVersion markers are recorded but never used to select behavior — DOMVersion / featureSet / readerVersion.

There is no backward-compatibility test matrix. We do not currently maintain a corpus of older-vintage packages that we assert parse correctly; our fixtures are generated against the modern DOM we target. A file from a markedly older vintage may parse fine — the additive shape makes that likely — but we make no guarantee we have exercised it.

Not yet parsedNo backward-compatibility test suite against older IDML vintages.

Multi-document constructs are not supported. A document assembled from several linked documents (a book) is outside what our parser and scene builder handle today; we read a single self-contained package, not a set of cross-linked ones.

Not yet parsedBooks / linked documents — multi-document assembly is not parsed.

None of these is a claim that the file is malformed — only that our reader, today, treats the version markers as facts to record rather than instructions to obey, and scopes itself to one modern, single-document DOM.

Frequently asked questions

What survives an IDML round trip? The structural facts the interchange form writes down explicitly: page and spread geometry, the text and the order it flows in, the styles and how they cascade, the colors and swatches, and the references that bind the parts together. These are what a second tool needs to reconstruct the document, so they make the full trip out and back without loss.

What does not survive a round trip? Two kinds of things. First, results recorded as values rather than live instructions — for example, a text variable is stored as the text it resolved to at export, not as a standing order to recompute it. Second, the application's private working state — caches, undo history, selection, and editor-only bookkeeping — which never enters the XML because it belongs to one session, not to the document.

Does Paged do version negotiation when reading IDML? No. The parser targets one modern DOM and reads every package through the same path, whatever version it claims. It never reads DOMVersion, never decodes the featureSet bitmask, and never compares readerVersion against a supported floor. In practice this works because the format grows additively — the structure we target is present in the files we care about — but it is a real limitation we are precise about.

Can Paged open a book or multi-document project? No. A document assembled from several linked documents — a book — is outside what our parser and scene builder handle today. We read a single self-contained package, not a set of cross-linked ones. This is not a claim that such a file is malformed, only that we scope ourselves to one modern, single-document DOM.