# ADR-101 SVG Is the Working Format for Print Creatives; CorelDRAW Is Fallback Only

## Status

Accepted, 2026-07-02.

## Status History

```yaml
status_history:
  - date: 2026-07-02
    status: Proposed
    changed_by: hkl
    reason: Creative pipeline MDD Phase 2 originally required a laptop CorelDRAW COM bridge for every adjustment and TIF export
    changed_via: adr-kit (360lm)
  - date: 2026-07-02
    status: Accepted
    changed_by: hkl
    reason: User decision — SVG is the interchange format (like DXF in engineering); recorded as MDD Phase 2A
    changed_via: adr-kit (360lm)
  - date: 2026-07-02
    status: Accepted
    changed_by: hkl
    reason: Refined by ADR-102 — conversion source for MODERN cdr must be CorelDRAW (CloudConvert svg+pdf routes proven content-lossy); SVG-centric processing unchanged
    changed_via: adr-kit (360lm)
```

## Context

Client creatives arrive as proprietary `.cdr`; the deliverable to the printer is a TIF
(final size @ 100 DPI, CMYK, LZW — profile extracted from a real deliverable, see
`printing/MDD_creative_pipeline.md` §2). Nothing except CorelDRAW can WRITE `.cdr`, so the
original design routed all adjustments and exports through a CorelDRAW COM bridge on the
user's laptop — making automation depend on a desktop machine being on. However: the
deliverable is TIF, not `.cdr`; SVG is the universal graphics interchange format; VCC can
edit SVG natively (cad-proxy `read_svg`/`write_svg`); and vector→raster scaling at export
time makes proportional resizes a render parameter rather than an edit.

## Decision

- The working format for print-creative processing is **SVG**:
  `.cdr → CloudConvert → SVG → adapt (or nothing) → render → CMYK TIF` — fully on the VPS.
- `SCALE_OK` cases (see `vcc-creative-check` verdicts) need **no editing at all**: render the
  SVG at `target_inches × 100 px`; scaling happens losslessly at rasterization.
- Content edits (text, colors, positions) are performed directly on the SVG by VCC.
- **Two gates before this path serves client work**:
  1. Per-creative visual diff: rendered SVG vs the CDR's embedded thumbnail (both free).
  2. One-time physical test print vs a designer-made TIF to validate RGB→CMYK conversion
     (ICC profile) — brand colors are the acceptance criterion. Until it passes,
     print-final TIFs continue to come from CorelDRAW.
- CorelDRAW (laptop, COM automation) is **fallback only**: effects that don't survive
  cdr→svg conversion (powerclips, envelopes, gradient meshes), or the rare case where a
  client requires an edited `.cdr` returned.

## Alternatives Considered

1. **CorelDRAW COM bridge as primary (original MDD Phase 2).** Rejected as primary: ties a
   server pipeline to a desktop machine; kept as fallback for fidelity edge cases.
2. **Cloud API for direct cdr→tif.** Rejected for finals: no color-managed CMYK control and
   no adjustment step; acceptable for preview thumbnails only.
3. **Ask clients to send SVG/PDF instead of cdr.** Not controllable — intake must accept
   what agencies actually send.

## Consequences

- Pipeline is headless and 24/7; laptop only needed for fallback cases.
- New VPS dependencies when Phase 2A is built: SVG renderer (resvg or Inkscape) +
  ImageMagick/Ghostscript with an agreed ICC profile for CMYK TIFF output.
- CloudConvert API key becomes the critical external dependency (per-conversion credits;
  141 MB files convert slowly and produce ~1.8 GB SVGs — streaming-safe handling required).
- The color gate is non-negotiable: wrong CMYK on a flex run costs more than any API fee.