Define the reusable signature appearance contract #9061

Goal

Document and define the reusable signature-appearance contract that future editor, preview, PDF rendering and AI-assisted authoring work must follow.

This is an architecture and planning task. It does not implement a new template engine, editor, renderer or AI feature.

The contract must first serve normal LibreSign functionality. AI is only a future consumer of that contract.

Current-state inputs

Before deciding the future contract, document and review the current behavior of:

• signature footer/template editing;
• Policy Workbench signature-footer configuration;
• preview generation;
• signature stamp rendering;
• PhpNative appearance/XObject generation;
• other renderer-specific differences;
• current template variables/placeholders;
• Unicode behavior and PhpNative engine: non-ASCII characters in the signature stamp are rendered as mojibake #8155.

Use code and tests as the source of truth.

LibreSign/documentation#113 documents the current signature appearance and preview pipeline and must be completed/reviewed as factual input before this synthesis is finalized. That documentation task must not decide the future appearance contract.

Contract to define

Document the minimum stable representation and rules for:

1. appearance/template content;
2. supported layout/formatting;
3. variable/placeholders and their types;
4. default/fallback behavior;
5. validation errors;
6. safe style/markup subset if markup is used;
7. preview input/output;
8. final PDF/XObject rendering input;
9. Unicode/font requirements;
10. compatibility/migration for existing stored templates;
11. renderer-specific capabilities/fallbacks.

Do not choose raw HTML, Twig, JSON/AST or another representation because it is convenient for AI. Select or document a representation only after current product/rendering requirements are understood.

Restricted execution

If a template engine is part of the future contract, define an intentionally restricted environment.

The contract must exclude:

• arbitrary functions or PHP execution;
• filesystem access;
• remote/network resources;
• unrestricted includes/imports;
• scripts/event handlers;
• unrestricted CSS or URL-bearing constructs;
• unknown placeholders that silently produce misleading signed output.

Invalid or unsupported input must fail predictably before signing.

Unicode and fonts

Use #8155 as concrete evidence that text encoding/font behavior must be part of the contract.

Document:

• which character ranges the future contract must support;
• how unsupported characters are handled;
• renderer/font requirements;
• how preview and final output remain consistent.

Do not implement the Unicode fix in this architecture task.

Preview and final rendering

The contract must make clear that preview and final PDF rendering consume the same validated semantic representation.

Document any renderer-specific differences that cannot currently be eliminated.

UX input

The contract must expose enough information for future editor UX to know:

• which formatting controls are meaningful;
• which variables can be inserted;
• which validation errors need to be shown;
• what preview can reproduce accurately;
• which advanced implementation concepts should remain hidden from normal users.

Do not implement the editor in this issue.

Required architecture artifact

Store the final contract in durable project-owned documentation.

It must include:

• current-state summary;
• chosen/future representation;
• allowed variables;
• validation/sanitization boundary;
• preview/rendering boundary;
• Unicode/font behavior;
• compatibility/migration rule;
• explicit non-goals and unsafe constructs.

Downstream handoff

Before this issue is complete:

1. review Modernize signature appearance templates and PDF rendering #9048 against the documented contract;
2. review Add AI-assisted signature appearance authoring #9049 against the documented representation, variable registry, validator/sanitizer, preview and rendering boundaries;
3. update those epics where assumptions differ;
4. do not create AI implementation issues based on an older assumed format.

Out of scope

Do not:

• implement a new template engine;
• modify the production editor;
• modify the renderer;
• fix PhpNative engine: non-ASCII characters in the signature stamp are rendered as mojibake #8155;
• add AI authoring;
• add new template variables.

Done when

• A single reusable signature appearance representation is documented.
• Validation/sanitization rules are explicit.
• Variable/placeholder behavior is explicit.
• Preview and final-render boundaries are explicit.
• Unicode/font behavior is explicit.
• Existing stored templates have a compatibility/migration rule.
• Unsafe execution/resource access is excluded by contract.
• The contract is stored in durable project-owned documentation.
• Modernize signature appearance templates and PDF rendering #9048 and Add AI-assisted signature appearance authoring #9049 have been reviewed against the final contract.