Conditional text
Conditional text lets one IDML document carry several versions of its words, with runs shown or hidden depending on whether a named condition is visible.
Conditional text lets one IDML document carry several versions of its words, showing or hiding runs by toggling named conditions.
In short: Conditional text is the IDML mechanism for keeping more than one version of a document's wording inside a single file. A phrase, a sentence, or a whole paragraph is tagged with a named condition, and that text appears only when the condition is switched on — a draft watermark that never reaches print, a price line that differs between regions, an instructor's answer key hidden in the student edition. The text always stays in the file; what changes is whether the condition governing it is visible. This page explains what conditional text is, the two pieces that make it work, and the line our renderer draws between what it composes onto the page and what it leaves to the editor.
Conditional text lets one document carry more than one version of its words. A phrase, a sentence, or a whole paragraph can be tagged so that it appears in some outputs and vanishes in others — a draft watermark that never reaches print, a price line that differs between regions, an instructor's answer key hidden in the student edition. The text stays in the file; what changes is whether a given condition is switched on.
In IDML this rests on two ideas working together:
- A
<Condition>is a named, on/off visibility toggle declared once at the document level (inResources/Styles.xml). It records whether it is currentlyVisible, and how an editor should mark the text it governs. - A run of text opts in to one or more conditions through an
AppliedConditionsattribute on its<CharacterStyleRange>. The run is laid out only when every condition it names is visible.
So the unit that gets shown or hidden is the run — the same
CharacterStyleRange that already carries the run's font, size, and colour (see
story structure). Conditional text adds one
more attribute to it and one small table of toggles beside it.
What our renderer does
This is the part worth being precise about, because the construct is partly a rendering feature and partly an editor feature, and we draw a hard line between them.
The rendering half is honoured. When a run names a condition that resolves to hidden, the run is dropped before layout — it contributes no glyphs, no width, nothing. The visible text simply closes up around the gap.
Supportedrun-level conditional visibilityThe editor half is not drawn. A condition also records how its text should be flagged on screen — an underline or a coloured highlight — and a document can group conditions into named sets that an author toggles as a unit. Those exist to help a person author the file; the page output does not depend on them, so the renderer reads them and moves on.
Where to go next
- Conditions and applied conditions
is the reference: the attributes on
<Condition>and<ConditionSet>, and how a run names them. - Visibility resolution explains exactly when a run is kept or dropped, and which pieces are parsed-not-rendered.
Frequently asked questions
What is conditional text in IDML? Conditional text is a way to keep several versions of a document's wording in one IDML file. Runs of text are tagged with named conditions, and a run is laid out only when every condition it names is visible — so the same file can produce a draft, a regional variant, or a student edition depending on which conditions are switched on.
What does Paged's renderer actually do with conditional text? It enforces run-level visibility: a run governed by a condition that resolves to hidden is dropped before layout, contributing no glyphs and no width, and the visible text closes up around the gap. The editor-facing pieces — how a condition flags its text on screen, and how conditions are grouped into sets — are parsed for round-trip but never drawn.
Where are conditions defined in an IDML file?
A <Condition> and any <ConditionSet> are declared once at the document level,
in Resources/Styles.xml. A run opts in to one or more conditions through an
AppliedConditions attribute on its <CharacterStyleRange> inside a story.
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.
Conditions and applied conditions
The <Condition> and <ConditionSet> elements in Styles.xml, the attributes our parser reads from them, and how a run opts in through AppliedConditions.