Bring Word Tracked Changes Back to the Source
When an edited Word document comes back, map every change to the Markdown or LaTeX master, then regenerate each deliverable from the updated source.
People who write long documents in Markdown or LaTeX dread receiving a Word file covered in tracked changes from a client, only to end up treating the DOCX as the new master. The product takes the original source files from a text repository and the edited Word file, then maps them by headings, paragraphs, and neighboring sentences rather than forcing a character-position match.
Tracked changes, comments, deletions, and paragraph moves are reconstructed as a reviewable set of patches. Authors can accept a wording change sentence by sentence, see where a passage was moved, or retain an editor’s note as a comment alongside the source. Changes whose location cannot be determined are listed separately with the original Word paragraph, so content is never changed silently in the wrong place.
Once patches are confirmed, the product writes them back to the Markdown or LaTeX master and regenerates Word, PDF, and web versions from that same source. Each export retains the current editing version, making it easy for authors to show clients which feedback has been adopted and which points remain open.
The first release focuses on body text, headings, footnotes, and ordinary comments. Complex tables, embedded graphics, and heavily manual formatting stay in a review queue, where the author can decide whether to reconnect them manually.
Why now
Pandoc’s twentieth-anniversary retrospective was published on August 2, bringing DOCX round trips and tracked-change recognition back into discussion. S1 When observed on August 4, the post ranked 12th on Hacker News, with 88 points and 11 comments, making it easier for source-manuscript authors to encounter the problem of writing Word feedback back into their source files. S2
Target user
People maintaining long-form work in Markdown, Quarto, R Markdown, or LaTeX. After delivery, clients or collaborators will only make tracked changes in Word. By the time the file returns, the source repository may have moved on. The author needs to absorb the feedback without letting DOCX replace the buildable, traceable master.
Minimal entry point
Start with the original Markdown or LaTeX file and the DOCX returned by the client. Use Pandoc’s DOCX reader and `--track-changes=all` to extract revisions, comments, authors, and timestamps. S3 Split the source into headings, paragraphs, sentences, and footnotes while retaining byte ranges. First narrow candidates by heading path and neighboring paragraphs, then use textual similarity to identify rewrites and moves. Patches modify only matched source ranges rather than rewriting the whole document. The first release supports Pandoc Markdown and consistently structured LaTeX; tables, drawing environments, and cross-paragraph comments go to manual review.
Punching above its weight
Reach initial users through Pandoc, Quarto, R Markdown, and academic-writing communities. Release a local command-line version so users can test real papers and technical white papers against it. Use before-and-after examples to show comments, paragraph moves, and footnotes returning as Git commits. Then offer a GitHub Action that automatically generates a downloadable patch-review page when a DOCX arrives.
Competitors & gaps
- Pandoc with manual diffingGoogle
- Pandoc can already read DOCX and preserve insertions, deletions, and comments with `--track-changes=all`. Reviewer names and timestamps also enter its intermediate representation, where filters can further process those nodes. S3 It excels at format conversion and can generate DOCX, PDF, and web output from the same source. But its official workflow does not realign an edited DOCX with the original source file. Users must either accept the entire Word output or parse the markup and compare text themselves. Complex structures such as tables may also lose detail in conversion. The opening is paragraph-level correspondence, move detection, and item-by-item write-back while preserving the original repository files' local style.
- SidedocGoogle
- Sidedoc already offers DOCX extraction, synchronization, diffing, and rebuilding. It separates body text, structure, styles, and assets into a `.sidedoc` directory, and supports attributed insertions and deletions. S4 This covers many Word round-trip editing needs and supports a broader range of table and image fidelity. Its public workflow currently extracts content from DOCX and syncs it back into the Sidedoc document system. Comments and footnotes remain unsupported, and an existing Markdown or LaTeX repository is not an explicit starting point for the workflow. The opportunity is the asymmetric case where the source manuscript comes first and Word returns later, with uncertain matches left for the author to confirm.
How it makes money
Charge a per-project subscription that includes local processing, version retention, and a set number of active documents. Put complex tables, bulk migrations, and team review permissions on higher-tier plans.
The case against
A mistaken paragraph match can write valid wording into a similar but unrelated location. Repeated sentences, renamed headings, and moves across chapters make mismatches more likely in long documents. LaTeX macros, citation commands, and conditional compilation can also make visible text diverge from source. To prevent silent corruption, low-confidence changes must be confirmed one by one, reducing the time-saving feel of automation. If complex DOCX structures lose information during conversion, users must also maintain a manual-fix list. Ultimately, the product depends not on conversion success rates but on whether authors trust it enough to write patches back to the main branch.