PDF Upload Visual Artifacts & Source-PDF Encoding

• PDF looks correct locally but wrong after upload, in OnlyOffice, after PDF→Word, or after a signature.
• Garbled / unreadable text (especially stamp paper, headers, or “agreement language”) in SpotDraft — or customer says “SpotDraft doesn’t read the language.”
• Same visual/text corruption in Slack preview, Mac Preview, Chrome built-in PDF viewer, and SpotDraft (suggests Pattern B, not SpotDraft-only).

Do not use for:

• Pure integration/API errors with no document attachment
• Template-generated contracts that fail for all customers (platform regression)
• Search/indexing of PDF text in a backend pipeline without a viewer symptom (may still be Pattern B — confirm with downloaded file)

Pattern A: Visual artifacts after processing (SpotDraft / OnlyOffice)

Symptoms: strikethroughs that appear only after sign, numbering breaks in OnlyOffice, column distortion after conversion, vendor stamp issues.

Known issue patterns

SpotDraft relies on PDF processing libraries and OnlyOffice. Problematic source PDFs often have:

• Hidden layers or unflattened annotations
• Non-standard font encodings (see also Pattern B)
• Complex nested lists that break DOCX conversion

Examples:

• SPD-42304: Strikethrough appears on a clause after first signature (Upload & Sign).
• SPD-42173: Numbering breaks in OnlyOffice vs Word (TPP).
• SPD-34608: Column formatting after PDF→Word.
• SPD-39288: Vendor stamps and signing/corruption.

Investigation (Pattern A)

1. Download the original customer PDF (before any SpotDraft processing if possible).
2. Open in Acrobat + Chrome. If the artifact already exists in the original → treat as Pattern B or malformed source first.
3. Determine when the issue appears: immediate upload, OnlyOffice, conversion step, or post-sign.
4. Try Chrome Print (below). If it fixes the issue → Pattern A mitigation applies.

Mitigation (Pattern A): Chrome Print workaround

Flattening often fixes processing artifacts:

1. Open PDF in Google Chrome.
2. Ctrl+P / Cmd+P → Destination Save as PDF → Save.
3. Upload the new file to a new contract (existing contract cannot be retro-fixed if baked in).

Pattern B: Missing ToUnicode CMap / broken text mapping (source PDF)

What went wrong (technical)

Many PDFs embed glyph outlines that look like letters but use non-standard character codes. A ToUnicode CMap maps those codes to Unicode so viewers and text extraction work.

If the CMap is missing or wrong:

• Most viewers (Chrome, Mac Preview, Slack preview, SpotDraft) show garbled text for affected runs.
• Adobe Acrobat may draw the page acceptably (glyph shapes) but copy/paste or text select can still be garbage — that is a strong signal for this pattern.

Plain-language explanation for CS: The tool that created the PDF did not embed correct character-mapping information for that text; viewers cannot turn the internal codes into readable Unicode.

Investigation (Pattern B)

1. Reproduce outside SpotDraft
   Open the same file in Chrome PDF, Mac Preview, Slack attachment preview. If all show the same garbling → not a SpotDraft viewer bug.

2. Check customer’s own evidence
   If their screenshot before upload already shows garbled text → source file was already bad (confirmed in incident SPD-41442 thread).

3. Acrobat behavior
   If Acrobat displays readable glyphs but copy/paste is wrong → consistent with missing/broken ToUnicode for that text.

4. Do not assume Chrome Print will fix it
   In SPD-41442, engineering tried:

   • Chrome Print — failed (Chrome could not render properly).
   • Acrobat: open → export as new PDF — still did not fix.
     When both fail, SpotDraft cannot fix the file; the customer must obtain a new PDF from the system that produced the stamp paper (e.g. re-export from vendor tool, different PDF generator, or professional PDF repair that re-embeds fonts + ToUnicode).

Mitigation (Pattern B)

• Customer action: Regenerate or replace the PDF at the source (issuer of stamp paper / agreement). Upload a new contract version in SpotDraft if workflow allows.
• Internal: Close engineering loop if cross-viewer reproduction is confirmed; mark blocked on customer / mitigated per process.
• No BQ/Groundcover required for confirmation — evidence is the binary PDF + multi-viewer check. Optionally attach file hash / contract {contract_id} for audit.

Confirm / disprove

Escalation triggers

Pattern A — escalate to Engineering (#pod-editor / #pod-signing by trigger):

• Chrome Print does not resolve and corruption appears only after a specific SpotDraft step (and not in raw viewers).
• Batch of standard SpotDraft-generated PDFs affected (platform regression).

Pattern B — do not burn eng cycles on “viewer fix”:

• Multi-viewer reproduction + failed Chrome/Acrobat repair → customer source PDF; document and hand back to CS.

Related incidents & Jira

Connections to other skills

• contract-lookup — Resolve {contract_id} → workspace, cluster, document URLs.
• contract-signing-triage — If symptom is strictly signing failure with a healthy-looking PDF, branch there.

Architectural note (high level)

Customer PDF → upload → SpotDraft storage → viewer (e.g. PDF.js / embedded) / OnlyOffice / conversion / signing

• Pattern A: Failure introduced or exposed along this pipeline.
• Pattern B: Bytes on disk already lack proper text mapping; every stage sees the same garbage.