[Prepress] Add PDF/X and PDF/A conversion, not only validation

[mberrys]

Part of #155.

Problem

Loupe has no path to produce a standards-conformant PDF. #21 covers PDF/X policy validation and normalized conformance findings — reporting whether a file conforms. Nothing converts a file to conformance, and PDF/A is not addressed at all.

Verified: no PDF/X or PDF/A conversion path in the engine or PdfTool; no output-intent authoring; no /GTS_PDFXVersion writing; no PDF/A identification metadata.

For the target user this is a routine daily requirement, not an advanced feature:

• Trade printers, brand owners, and ad-delivery specs demand PDF/X-1a, X-3, or X-4 as the exchange format. A shop that receives a non-conformant file and needs to deliver a conformant one currently has to leave Loupe.
• The wedge ends at "verified press-ready output". For a large share of real jobs, "press-ready" is a PDF/X conformance claim. Validating and reporting non-conformance without a remedy stops one step short of the product's own stated outcome.
• PDF/A matters for the archival copy of a job — a real requirement for regulated and government print work, and a natural fit for a product that already keeps an operation ledger.

Scope

1. Conversion to PDF/X, targeting the parts that matter commercially: X-1a (requires flattening — see the transparency-flattening issue in this epic), X-3, and X-4. Cover output-intent embedding, colour-space normalization, font embedding, transparency policy, and the metadata/identification the standard requires.
2. Conversion to PDF/A, at the level actually needed for archival deliverables, with the conformance level explicitly chosen and recorded rather than implied.
3. A pre-conversion report: what will change, what cannot be made conformant automatically, and what requires an operator decision. Conversion that silently alters colour or substitutes a font is exactly the opaque behaviour the product boundary rules out ("not an opaque generative editing system for production PDFs").
4. Post-conversion validation using an independent validator, not the engine that performed the conversion. Self-validation of a conversion is not evidence. docs/PACKAGING_LICENSING.md already contemplates optional veraPDF — settle that dependency here, including its licensing consequences.
5. Registration as a semantic operation under the shared contract, available identically from Editor, PdfTool, and PageMaster.
6. Record the claim boundary: which standards and levels Loupe asserts it can produce, and which it can only validate. An overstated conformance claim is a commercial liability.

Acceptance criteria

• Conversion to each supported target produces output that an independent validator accepts.
• Conversion that cannot reach conformance fails with a report naming each blocking condition, and never emits a file claiming conformance it does not have. A wrongly-claimed /GTS_PDFXVersion is worse than no conversion.
• The pre-conversion report enumerates colour, font, and transparency changes before execution.
• Revalidation runs automatically after conversion ([0.3.0-C] Automatically re-preflight after every fix #129), and the resulting preflight verdict reflects the converted file.
• Identical semantics across Editor, PdfTool, and PageMaster.
• The supported-standards claim is documented and matches what the tests cover.

Test strategy

• Fixture set per target: already-conformant input (must be a no-op or a minimal, justified change), convertible input, and unconvertible input (must fail closed).
• Independent validation of every output.
• Colour-fidelity check: differential rendering before and after conversion, on the Build a differential prepress-rendering corpus for color, transparency, spot inks, and overprint #87 corpus.
• Negative test: assert no output carries a conformance claim without passing independent validation.

Dependencies

• Add PDF/X policy validation and normalized conformance findings #21 — PDF/X policy validation; supplies the conformance model this converts toward.
• The transparency-flattening issue in this epic — hard prerequisite for X-1a.
• Validate output-intent and ICC-profile presence, identity, and color-space consistency #12 / Implement ICC-managed RGB-to-CMYK conversion with proofing and revalidation #20 — output intent, ICC profiles, and colour conversion.
• Implement font embedding/subsetting with license and substitution safeguards #82 (closed) — font embedding and subsetting with licence safeguards.
• docs/PACKAGING_LICENSING.md — veraPDF is already flagged as an optional dependency with licensing implications; this issue forces the decision.

[mberrys]

Alignment status — 2026-08-10

PR #258 repairs the standards-conversion integration regressions required to compile the preview/apply path. Keep this issue open: conversion output must not receive a PDF/X or PDF/A conformance marker unless an independent validator confirms it, and convertible/unconvertible fixtures must remain explicit. Independent validation is owned by #241; recovery/qualification is tracked by #259.

[mberrys]

Status check — 2026-09-02

Investigated current state before implementing. Most of this issue's scope already exists and is registered/wired: standards-convert (LoopLibCore/sources/pdfstandardconversion.{h,cpp}) converts to PDF/X-1a:2001, PDF/X-3:2002, PDF/X-4, and PDF/A-2b, produces a pre-conversion change report, is fail-closed, requires an independent validator before committing (never self-certifies), and is exposed identically through PdfTool's repair command and PageMaster's export job. veraPDF's licensing decision is settled in docs/PACKAGING_LICENSING.md (MPL 2.0, optional add-on pack, never bundled).

Opened #524: it wires the existing PDFTransparencyFlattener operation (#164) into standards-convert, so live transparency is no longer an unconditional blocker for PDF/X-1a/X-3 (the issue calls flattening out as "a hard prerequisite for X-1a"). Flattening is default-on for X-1a/X-3, opt-in elsewhere, and reported as a real content change, never a silent approximation.

Two remaining gaps I did not implement, with reasons:

• Editor integration ("identical semantics across Editor, PdfTool, and PageMaster") — docs/loop-shell.json's plugin surface policy currently retires all legacy Editor plugins from install, and docs/LOOP_SHELL_CONTRACT.md states product GUI work is gated behind the still-closed S21/S22 admission contracts. docs/STANDARD_CONVERSION.md previously said this could land "after the 0.1.1 GUI gate" — that gate is actually already complete, so Wire transparency flattening into standards-convert (#167) #524 corrects the doc to point at the real (still-closed) gate instead. Also flagging: docs/REPO_MAP.md's LoopEditorPlugins/ module doesn't exist in the current Qt-Quick tree; a future adapter belongs under LoopLibInteraction/ + LoopEditor/qml/.
• PDF/X-3 and PDF/X-4 fixture-level conversion tests (this issue's own "fixture set per target" test-strategy bullet) — only PDF/A-2b and PDF/X-1a have apply()-level oracle tests today. Per this issue's Aug 11 comment, independent-validation fixture work is owned by [0.2.1] Institutionalize independent standards and renderer validation #241 ("Conversion fixtures... PDF/X-4 before broader variants" is explicitly [0.2.1] Institutionalize independent standards and renderer validation #241's scope), so I left that there rather than duplicating scope.

Font embedding/subsetting also remains detection-only (no repair operation), unchanged by #524 — a separate, larger undertaking than issue #82 (which covered detection, not remediation).

---

Generated by Claude Code