Epic: Offline visual PDF editing

[McanKul]

Outcome

Deliver a trustworthy offline PDF editing roadmap without implying that every PDF can be edited like a Word document.

Proposed delivery order

• Build the reusable visual PDF editor canvas #6 — reusable visual editor canvas
• Add text, image and shape overlays to PDF pages #7 — add text, images and shapes (depends on Build the reusable visual PDF editor canvas #6)
• Add comments, highlights and drawing annotations #8 — comments, highlights and drawing annotations (depends on Build the reusable visual PDF editor canvas #6)
• Detect and fill existing AcroForm fields #9 — fill existing AcroForm fields (can reuse Build the reusable visual PDF editor canvas #6)
• Implement secure content redaction with explicit verification #10 — secure redaction and verification (depends on Build the reusable visual PDF editor canvas #6)
• Spike: evaluate safe editing of existing PDF text and images #11 — spike for changing existing text/images

Product boundary

The initial Edit PDF experience adds content through overlays and standard annotations while preserving the original page content. Replacing existing text/images is not promised until #11 demonstrates a safe, clearly bounded subset.

Shared definition of done

• Fully local/offline processing; no new telemetry or network calls.
• Original input is never overwritten.
• Correct coordinates for CropBox/MediaBox and all page rotations.
• Explicit handling of encrypted, malformed and very large PDFs.
• Output validation with qpdf check plus interoperability fixtures.
• Accessible keyboard path for editor controls.
• Contributor documentation and automated tests accompany each shipped capability.

Architecture direction

• React/pdf.js: rendering, selection and interaction.
• A typed page-space edit model: UI/backend boundary.
• Rust/lopdf: PDF object and content construction where appropriate.
• qpdf: assembly, normalization, validation and optional annotation flattening.
• Bounded decoding and file-size guards for untrusted documents.

Research notes

• qpdf handles structural operations and annotation flattening, but its form appearance generation is limited.
• lopdf exposes content streams and annotations, but loading/manipulating arbitrary PDFs needs explicit memory and decompression limits.
• Existing-text editing is complicated by subset fonts, glyph mappings and nested content streams; it remains a spike rather than an MVP promise.

v0.4 direct editing foundations

• research(editor): add a representative source-editing fixture corpus #32 — representative source-editing fixture corpus
• spike(engine): prototype a read-only source-content capability classifier #33 — read-only source-content capability classifier
• test(editor): validate and round-trip edited PDF outputs before publish #34 — fail-closed output validation and round-trip gate
• feat(editor): add, edit and remove PDF link annotations #35 — add, edit and remove PDF link annotations

Existing text/image replacement remains gated by #11. Follow-up production issues should cover only the supported subsets demonstrated by the spike; unsupported PDFs must fail explicitly rather than silently falling back to an overlay.