AEM Forms Developer Expert study materials
AEM Forms Developer Expert study resources

Output That Renders Differently on Publish

AEM Forms Developer Expert · Put your knowledge to work in context.

All case studies

Output That Renders Differently on Publish

A government agency generates PDF confirmation letters from submitted Adaptive Form data using a Document Services output service on AEM. Letters render correctly on author but on publish the generated PDFs show a fallback font, truncated tables, and a missing agency logo. The letter template uses an XDP with embedded fonts and an image reference to a DAM asset. The publish tier has two nodes; the author tier has one. The output service is invoked from a workflow step. The agency also needs the generated letters retained for seven years with an audit trail of who generated them.

1. Diagnose the font, table, and logo differences between author and publish.

Read the worked answer

All three are environment/resource resolution problems, not template logic:

  • Fallback font: the XDP's embedded fonts are not available to the output service on publish. Fonts must be installed/available to the rendering engine on each node; author had them, publish does not. Two publish nodes means the fix must be applied to both.
  • Truncated tables: usually a data/font-metrics interaction - if the fallback font has different metrics, table columns overflow or wrap and content is clipped. Fixing the font often fixes the truncation; verify separately.
  • Missing logo: the DAM asset reference resolves on author but not on publish - the asset was not activated to publish, or the reference points at an author-only path. Assets used by output must be activated to every publish node.

The two-node publish tier is a trap: a fix applied to one node produces intermittent correct/incorrect output.

2. Design the retention and audit approach for seven-year letter retention.

Read the worked answer

Do not rely on the transient output of the workflow step. Persist deliberately:

  1. Store the generated PDF in a durable, versioned repository (DAM or a dedicated archive) with a retention policy of seven years, not in a temp/work location that gets cleaned.
  2. Capture an audit record at generation time: who submitted, who/what generated the letter, timestamp, template version, and a hash or ID linking the audit record to the stored PDF. The template version matters - a letter regenerated later must be attributable to the template used.
  3. Make generation idempotent and traceable: the workflow step should write the audit entry in the same transaction/flow as the PDF store, so a crash cannot leave a letter with no audit trail or vice versa.
  4. Verify on both publish nodes that the archive target and audit sink are reachable and consistent; with two nodes, confirm no duplicate or split records.

Retention is a records-management requirement, so validate that the archive survives package deployments and node failover - a letter that exists only on one node is not retained.