Bench 01·editors_trial·2026

DOCX editors, re-verified against code.

Each editor's own code imports one purpose-built adversarial document and exports it again. The reports below take that result apart by namespace, by pass-through, by malformed part, by what each editor puts on the page, and by what it does with hostile input.

The field · 13 tools and a baseline

Every tool here leads somewhere.

Where each editor places best, round trip and hostile input side by side, with links into the reports that measured it.

See the field →

/ Reports

Main report

Open-Source DOCX Editors, Re-verified Against Code and Measured by Round-Trip (2026-11-01)

2026-11-01

This edition does what the previous one could not: it downloads every editor's code, runs each editor's own import→export path over a purpose-built adversarial document, and scores the result. Every cell that previously read NOT VERIFIED IN CODE is now either a source citation or a measurement.

Report A

Serialization: What Each Namespace Does, and What It Costs When It Is Lost (2026-11-01)

2026-11-01

A companion to Open-Source DOCX Editors, Re-verified Against Code and Measured by Round-Trip (2026-11-01), and the first half of what used to be Report A. That report asked how faithfully each editor preserved a document, and answered with a single number. This one opens the question up: a DOCX file is not one thing but twenty-seven vocabularies, and an editor does not preserve or lose "a document" — it preserves or loses each vocabulary, in its own way, for its own reason.

Report A2

Pass-Through: What Each Editor Copies, and What That Costs (2026-11-01)

2026-11-01

A companion to Open-Source DOCX Editors, Re-verified Against Code and Measured by Round-Trip (2026-11-01), and the second half of what used to be Report A. The first report asked how faithfully each editor preserved a document and answered with a number. Serialization by Namespace opened the question up vocabulary by vocabulary. This one asks the complementary question: of the bytes that came out, how many did the editor never even look at?

Report B

Malformed Parts: Causes, Detection, and Repair (2026-11-01)

2026-11-01

A companion to Open-Source DOCX Editors, Re-verified Against Code and Measured by Round-Trip (2026-11-01) and to What Is Serialized, What Is Pass-Through, and What Is Actually Rendered (2026-10-30).

Report C

Rendering: What Each Editor Actually Shows, Measured Against Word (2026-11-01)

2026-11-01

Part C of the series. Part A covers serialization by namespace, Part A2 covers pass-through. This part answers one question: when you open the corpus in each editor's own running application, what does that application put on the page — and how does it compare with what Microsoft Word puts on the page?

Report D

Report D — Safety, Resource Bombs and Hostile Input (2026)

2026-11-02

No editor is safe on every package. Safe here means the weapon is not in a finished document and the process did not hang or run out of stack. A named ceiling is stronger than a bare refusal. A bare refusal is stronger than a hang. Keeping the weapon is not safe. Word was not opened in the seatbelt matrix. A separate Word run is in Report D2 - What Word Protects Against (2026).md, final since 2026-10-31; its results are copied at the end of this report.

Report D1

Report D1 — Jubarte on the Hostile Packages (2026)

2026-11-02

Jubarte is not one of the editors in Report D. This file is only the release binary of ../jubarte-redlines.

Report D2

Report D2 — What Microsoft Word protects against, and what it does not (2026)

Interim

This report records what Word does with each hostile package: whether it opens it, warns, refuses, hangs or crashes, how much memory it takes, and whether it reaches the network. It is the reference the editors in Report D are compared against when we say a refusal "costs no Word-valid input".

/ Notes

/ Lane notes · one per tool