# Long transcript with inline images: reliable PDF fallback

Use this workflow when the source is a long chat/audio transcription and the requested editable cloud document cannot reliably accept inline images.

## Deliverable contract

- Preserve the **full** chronological dialogue; do not substitute an abridged body plus an external “full version.”
- Attribute every message consistently (for example, `Настя:` / `Маргарита:`).
- Keep replies, text reactions, emoji, links, and thematic notes in sequence.
- Deduplicate only exact or clearly repeated whole messages. Do not remove natural repetition inside speech.
- Mark uncertain audio as `[неразборчиво]`; never reconstruct it from context.
- Place every image at its original chronological marker, not in an appendix.

## Capability decision

1. Test whether the target editor can persist a harmless text edit.
2. Separately test whether it can create a real embedded image object.
3. If text works but image insertion is unavailable or disabled, do not keep fighting the cloud editor and do not report completion.
4. Offer or produce a self-contained PDF/DOCX with embedded media when the user accepts that fallback.

A public Google Doc may permit anonymous text editing while disabling **Insert → Image**. Image URLs, links, or visible placeholders are not embedded images.

## Deterministic PDF assembly

A dependable local route is PyMuPDF (`fitz`) with a Unicode font such as DejaVu Sans:

1. Parse the cleaned transcript line by line.
2. Recognize stable image markers such as `[ИЗОБРАЖЕНИЕ: /absolute/path.jpg]`.
3. Render speaker names with distinct styles and dialogue text as paragraphs.
4. At each marker, insert the corresponding local image with proportional scaling and page-boundary checks.
5. Use a Cyrillic-capable font file explicitly; do not rely on PDF base fonts.
6. Save with compression/garbage collection enabled.

## Verification gates

Do not call the artifact ready until all applicable checks pass:

- PDF opens successfully.
- Page count and file size are plausible for the source.
- Extracted text contains sentinels from the beginning, middle, and end.
- Expected final messages are present.
- All image markers are gone.
- Embedded image-object count equals the expected image count.
- The pages containing images are identified programmatically.
- Representative pages (first, each image page, last) are rasterized and inspected for readable Cyrillic, clipping, overlap, and ordering.

For DOCX verification, inspect the ZIP package: real embedded images appear under `word/media/`. An empty `word/media/` means the images were not embedded, regardless of what the browser interaction appeared to do.

## Reporting

Report only verified facts: artifact path, page count, message/word count if measured, embedded-image count, placeholder count, and any source-image limitation (for example, a stock-photo watermark). Never say “done” while the requested images are still links, markers, or attachments outside the document.