DocX Lossless Editing Toolkit

What Problem It Solves

A .docx file is not just a text container; it is a ZIP package of XML parts, media, styles, headers, footers, and revision data. Regenerating the whole document often breaks existing styles, numbering, sections, fields, and Chinese typography, while naive string replacement can miss the w:r and w:t run structure that Word relies on.

How It Works

The skill treats .docx as an unpackable XML package and follows an unpack → edit in place → repack workflow:

• Read: inspect the structure, outline, and preview with docx_reader.py before changing anything.
• Edit: choose creation, fill-in editing, or format application, then use scripts such as docx_replace_text.py, docx_fill_placeholders.py, and docx_add_paragraph.py for local changes.
• Validate: run docx_validate.py and use docx_reader.py --diff-against to confirm only intended content changed.
• Render: generate PDF and PNG with docx_render.py, then visually check fonts, overflow, and layout.

It adds explicit CJK constraints, including UTF-8, w:rFonts w:eastAsia, font-size mapping, and GB/T 9704 official-document guidance. Headings also need w:outlineLvl, or they may disappear from the TOC or navigation pane.

Where It Fits

This is best for local edits, placeholder filling, and template restyling of existing .docx files, not for wholesale regeneration that discards the original package. Rendering depends on LibreOffice and poppler; if local CJK fonts are missing, the preview may substitute Noto, while the stored font name remains as authored.