Feature request: conditional token logic in page templates

I’d like to request conditional rendering support for tokens in page templates.

The problem

Tokens like {@arranger@} render as empty when the field is not filled in — which is fine. However, there’s no way to conditionally show or hide surrounding text (like a label, prefix, or line break) based on whether a field is populated.

Example: I want my first-page template to show this when an arranger is present:

John Williams
arr. Frank Sinatra

…and only this when the arranger field is empty:

John Williams

Currently this is impossible with a single template, because any static text — including line breaks — around a token is always rendered, regardless of whether the token resolves to anything.

Workarounds and why they fall short

  • Putting “arr.” inside the Project Info field conflates data with presentation
  • Creating separate page template variants per use case doesn’t scale — especially across a library of reusable templates

Proposed solution

Introduce a conditional block syntax, for example:

{@if:arranger@}{@endif@}

Everything between these tags would only render when the referenced field is non-empty. A negated form could also be useful:

{@ifnot:arranger@}{@endif@}

Crucially, the conditional should be able to wrap not just text and tokens, but also formatting elements like line breaks. A practical example:

{@composer@}{@if:arranger@}<newline>arr. {@arranger@}{@endif@}

This would render as composer + newline + "arr. " + arranger when the arranger field is filled in, and as just composer when it is not — with no trailing newline.

Use cases

  • Arranger, lyricist, dedicatee — fields that are often optional
  • Custom “Other Information” fields
  • Any label or prefix that should only appear alongside actual content
  • Line breaks between stacked contributor lines

This kind of conditional logic is standard in mail merge systems and templating engines, and would make Dorico’s token system significantly more powerful for professional template design. A single page template could then cleanly handle projects with and without optional contributors — without manual intervention or layout overrides.

4 Likes

Your request is very clearly written, thank you!

I should like to add an enhancement to your suggestion: create conditions like

{@if({@arranger@}="<string<>"{@}“”{@else@}””{@endif@}

where can be also a conditional function (i.e. nesting is possible).

And if we may dream a bit further: function-like capabilities like those in Excel would be fantastic…

1 Like

Your example is currently perfectly possible, as long as you’re not being too precious about ‘conflating data with presentation’, whatever that means. You can put line breaks in any Project Info field, as long as you paste them from elsewhere. You can apply basic Markdown formatting within a single field, or define your own character style tags. And of course, all of the token names are just suggestions, you’re free to use some of them for ‘data’ and others for ‘presentation’. The line break, the ‘arr.’ and the arranger name can all go in a single token which you leave empty when not applicable. Or use three different tokens if you want. And everything can go into one template, no overrides necessary.

While I would generally support a conditional token feature, I’m also eagerly awaiting enhancements concerning Dorico’s Lua scripting capabilities.

I envision Lua code being attached to text or system text (or any Dorico notation element) and modifying the element’s content or appearance right before rendering. This would be more versatile and easier to debug than a syntax or language specifically designed for conditional tokens.