Malformed packages

A package can be wrong in two ways: structurally, so nothing can be read, or locally, so one value or reference makes no sense. A reader has to refuse the first and should read past the second.

In short Every package needs a mimetype entry naming the IDML package type and a designmap.xml, and every part the design map names must be in the archive. Without those there is no document to assemble. Inside a complete package, most attributes are optional and their absence means "inherit", several values that look wrong are legal (-1 tints, n for no next frame, $ID/ names), and hand-edited files can contain references that name nothing, style chains that loop, and links to files that are not there. This page separates the format's rules from the tolerance a reader has to bring.

What must be there

A reader cannot start without three things:

• the mimetype entry, whose text is application/vnd.adobe.indesign-idml-package. InDesign writes it as the first entry in the archive and stores it uncompressed; all 271 InDesign-written packages in our corpus do;
• designmap.xml, the root part that names every other part (see the design map);
• every part the design map names. A design map that lists a story the archive does not contain describes a document with a hole in it: a frame names the story in ParentStory, the design map counts it in StoryList, and there is no text to put there.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<?aid style="50" type="document" readerVersion="6.0" featureSet="257" product="20.0(32)"?>
<Document xmlns:idPkg="http://ns.adobe.com/AdobeInDesign/idml/1.0/packaging" DOMVersion="20.0" Self="d" StoryList="ustory" Name="smallest-valid.indd" CMYKProfile="Coated FOGRA39 (ISO 12647-2:2004)" RGBProfile="sRGB IEC61966-2.1" SolidColorIntent="UseColorSettings" AfterBlendingIntent="UseColorSettings" DefaultImageIntent="UseColorSettings">
  <idPkg:Graphic src="Resources/Graphic.xml"/>
  <idPkg:Fonts src="Resources/Fonts.xml"/>
  <idPkg:Styles src="Resources/Styles.xml"/>
  <idPkg:Preferences src="Resources/Preferences.xml"/>
  <idPkg:Tags src="XML/Tags.xml"/>
  <idPkg:MasterSpread src="MasterSpreads/MasterSpread_umaster.xml"/>
  <idPkg:Spread src="Spreads/Spread_uspread.xml"/>
  <idPkg:Story src="Stories/Story_ustory.xml"/>
  <idPkg:BackingStory src="XML/BackingStory.xml"/>
</Document>

Parts the design map does not name are a different matter. Extra entries in the ZIP are not part of the document, and a reader can ignore them. A tool that writes the package back should keep them, because another application may have put them there.

Absence usually means "inherit"

Almost every attribute in IDML is optional. A CharacterStyleRange with no PointSize takes the size of its character style, then of its paragraph style, then of the styles they are based on, then the document default (see the cascade). A reader should treat a missing attribute as "not set here", never as an error.

There are exceptions where InDesign does not supply the obvious default. It does not read a missing ItemTransform as the identity: it places the item relative to the spread's first page, so on a facing spread every item meant for the right page lands on the left one. It needs PageCount and BindingLocation on every spread. Those rules matter to a writer more than to a reader; what InDesign needs to open a file lists them.

Values that look wrong but are legal

A reader that rejects these, or reads -1 as a tint of minus one per cent, misreads ordinary InDesign output.

What a reader should tolerate

These problems do not occur in packages InDesign writes, but they do occur in packages edited by hand or generated by other tools.

• A reference that names nothing. A FillColor, AppliedParagraphStyle or ParentStory can name an id that no element defines. Falling back to the default (no fill, the base style, an empty frame) keeps the rest of the document readable.
• A chain that loops. A style can be BasedOn itself through a ring of other styles, and a thread of NextTextFrame links can return to its first frame. A reader that follows these chains needs a limit.
• A value it does not know. A newer InDesign writes attributes and enumeration values an older reader has never seen; the DOMVersion on each part says which revision wrote it (see version markers). Skipping an unknown value, and keeping it if the package is written back, is the forward-compatible answer.
• A link to a file that is not there. A placed image names its file by LinkResourceURI, and the file often does not travel with the package. InDesign keeps the frame, its geometry and its crop, and shows a missing-link placeholder.

How InDesign itself treats a package with a dangling part or a looping chain has not been measured for this reference.

In Paged: the import stops on the structural problems above, with an error that names the entry, and reads past the local ones: absent and unknown values fall back, chains are cut at a fixed depth, and missing images are drawn as InDesign's placeholder and reported. The details are in edge cases on the Paged site.

Supported · verified

Frequently asked questions

What is the minimum an IDML reader needs to open a package? A ZIP archive with a mimetype entry naming application/vnd.adobe.indesign-idml-package, a designmap.xml, and every part that design map names. A small complete package is taken apart on read one by hand, and can be downloaded.

Is a FillTint of -1 an error? No. -1 is how InDesign writes "no tint override" on a tint attribute. It means the same as leaving the attribute out.

What should a reader do with an attribute it does not recognise? Ignore it for reading, and keep it when writing the package back. IDML grows by adding vocabulary, so a file from a newer InDesign is mostly an older file plus things an older reader can skip.

Does a missing image make an IDML package invalid? No. The link is a URI to a file outside the package, and packages routinely travel without their images. The frame, its geometry and its crop are all in the XML; only the pixels are missing.