dsh-r7-office

LIMITATIONS

Known limitations

- **Presentations: building layouts or masters is out of scope.** Slides are created on the layouts the deck already contains; a deck that ships none gets the generic title/body pair. - **Presentations: SmartArt and charts are preserved, never authored.** The reader reports them (`type: "chart"`, `type: "graphicFrame"`) and every part behind them stays byte-identical through any edit, but the engine cannot create one. A hand-written SmartArt frame is just a `dgm:relIds` reference, and R7's own renderer dereferences the diagram parts behind it. - **Presentations: image replacement stores a fresh media part** when the format changes or the media is shared, so the old part can be left unreferenced. Everything that still points at it keeps working. - **Presentations: theme colours read back as tokens** (`scheme:accent1`), because no literal hex exists until the theme is resolved. Writing accepts literals only. - **Live desktop bridge: Windows verified.** The bridge plugin itself is platform-neutral, but the automated live test drives R7-Office Desktop through the CEF DevTools protocol and is only verified against the Windows build (`Editors-2026.3.1`). Other platforms should work; they are untested. - **R7 required for PDF.** `r7_convert` needs a local R7 installation for its `x2t` converter. Everything else works without it. - **Format coverage.** Reading and editing cover the common OOXML surface listed above. Charts, embedded objects, SmartArt and tracked changes are preserved but not editable through these tools. - **DOCX: not implemented in v0.1.0.** Replacing or resizing an *existing* image; assigning a table style (`tblStyle`); changing a hyperlink's target (retitle, or remove and insert instead); a convenience wrapper for per-section different headers (both can be read and preserved, and `r7_docx_header_footer` accepts `first`/`even` — for `first` also call `r7_docx_sections` with `titlePg`). Search is not revision-aware: `r7_replace` scans raw `<w:t>`, so text inside a tracked insertion is editable and paragraph indices count paragraphs inside deleted content — `<w:delText>` is never matched. - **DOCX: comments, tracked changes, footnotes, endnotes, a table of contents, equations and embedded objects are preserved, never edited.** A test asserts they survive an ordinary edit with every part byte-identical. - **DOCX to PDF: a thin horizontal line can appear through an italic subtitle.** A paragraph styled `Subtitle` (italic, centred, grey) may render with a faint line across it after `r7_convert`. The document contains no strikethrough, underline or paragraph border — `w:strike`, `w:u` and `w:pBdr` are all absent, and the same style applied to R7's own template renders cleanly through the same converter — so the line is introduced during PDF conversion and cannot be corrected from the document. It is cosmetic: the text itself is correct and extracts normally. Quantified at roughly 5 % more ink in that text band. - **PDF rendering is verified visually, not by text extraction.** A PDF can carry the right text, the right page count and a clean `validate()` while drawing the wrong glyphs or a solid block. `scripts/visual-acceptance.py` renders the output with two independent engines and compares against a LibreOffice render of the source; run it when changing anything in the conversion path. - **XLSX: not implemented in v0.1.0.** Cell styles are limited to the properties listed for `r7_sheet_format`; conditional formatting, data validation, charts, pivot tables and defined names are preserved but not editable. - **PPTX: SmartArt, charts, animations and transitions are preserved, never authored.** The engine cannot create SmartArt (a hand-written frame is only a `dgm:relIds` reference), and editing their content is out of scope. - **No concurrent editing.** File tools operate on a document at rest. For a document the user has open, use the des