Redlining Content

Redlining Content Skill

Reimplements "Word Compare" for the new Copilot Studio orchestrator. The

template is already a perfect Word document, so the output is the template

body with revisions injected as OOXML <w:ins> / <w:del> elements. Accepting

all changes yields the submission's wording; rejecting all keeps the template.

Changes are authored by Copilot Studio AI and the output has Track

Changes turned on so Word keeps tracking any further human edits.

Requirements

• lxml (always)
• pdfplumber (PDF submissions; pypdfium2 used as a fallback)

All are present in the Copilot Studio sandbox — no pip install required.

.docx/.dotx handling is pure lxml + standard library.

Inputs

• Template — the canonical baseline. Bundled with this skill in

assets/ (any single .dotx/.docx file — the name doesn't matter) and

used automatically. A different template (.dotx or .docx) may be

supplied explicitly to override it.

• Submission — the user-uploaded file to compare against the template,

either a .docx or a .pdf.

Steps

• Run from this skill's directory:

python scripts/redline.py <submission.docx|.pdf> [output.docx]

The bundled template in assets/ is auto-discovered and used as the

baseline (whatever its file name).

To override the template explicitly, pass it via --template:

python scripts/redline.py --template <template.dotx|.docx> <submission.docx|.pdf> [output.docx]

• Return the output .docx to the user. Output defaults to the submission

name with a _redlined.docx suffix.

How it works

One shared engine, two input readers — the only thing that differs by file

type is how the submission's words are read:

• .docx / .dotx → read_docx_words() (paragraph text from

word/document.xml).

• .pdf → read_pdf_words() (text extraction only — never converted to

DOCX; uses pdfplumber, then pypdfium2).

Both produce a single flat word list fed into the same pipeline:

• Word-level diff over the whole document. The template's words and the

submission's words are each flattened into one stream and compared once with

difflib.SequenceMatcher. PDF line-wrapping and paragraph boundaries are

therefore irrelevant — only real word differences matter.

• Each template word is mapped back to its source paragraph. Paragraphs with no

changes are kept byte-for-byte (all formatting preserved); only changed

paragraphs are rebuilt, with differing words wrapped in <w:ins> / <w:del>.

• Tables. For .docx submissions, template tables are diffed against the

submission's tables cell by cell (aligned by position: table → row →

cell), with <w:ins> / <w:del> injected directly into each cell while its

<w:tcPr> (width, borders, shading) is preserved. For .pdf submissions

there is no table structure to align, so template tables pass through

untouched and their words are stripped from the extracted text so they aren't

flagged as insertions.

• Writes the output zip: replaces word/document.xml, adds <w:trackChanges/>

to settings.xml, and converts the .dotx main-part content type to the

.docx one so the result opens as a normal document.

Per-input guidance

See the focused reference docs:

• references/docx-submissions.md — .docx handling, high-fidelity path.
• references/pdf-submissions.md — .pdf handling, why text is extracted (not

converted), the word-level diff, and table handling.

v1 limitations

• Inside a *changed* paragraph, intra-run character formatting (bold/italic

on individual words) is simplified to the paragraph's base formatting.

Unchanged paragraphs keep all formatting exactly.

• Tables: .docx table cells are diffed and redlined (aligned by position);

cells are matched by position, so inserted/deleted rows or columns and nested

tables are not tracked, and multiple paragraphs in one cell collapse to one.

.pdf tables are not diffed (passed through unchanged).

• A brand-new paragraph in the submission is tracked as inserted words at

the nearest template position; a hard paragraph break may not be recreated.

• Matching is by visible text; curly quotes/apostrophes are compared literally.