The protocol, rule by rule
Each rule settles one decision a parser has to make about a page — what to keep, and how to write it down. Every rule page states the requirement, shows real pages beside the output it expects, and explains how it differs from the rules next to it.
- Rules
- 140
- Chapters
- 13
- Real-document examples
- 364
Three principles behind every rule
Almost every rule exists to stop one of two failures: dropping what the page prints, or inventing what it doesn’t.
The output MUST represent the document as rendered: what a careful reader extracts from the pages, semantic structure over visual appearance, with text transcribed verbatim — typos included.
Every piece of printed content MUST survive into the output (never drop), and the output MUST NOT contain a label, value, span, header, structure or relationship that the page does not print (never invent).
- §2.3
Traceability
Every element of the output MUST be attributable to the place on the page it was read from. When boxes are requested, every Markdown element MUST have a box, and every box MUST cover exactly the printed content of its element.
Common cases to start with
Chapters
- §1
Conventions
3 sectionsHow to read the protocol: what MUST, SHOULD and MAY mean, what makes an output conform, and what each badge says.
- §2
Principles
3 sectionsThe three requirements every other rule exists to serve.
- §3
Output model
4 sectionsThe shape of a conforming output: elements, one Markdown file, boxes and the sidecar.
- §4
Document level
6 sectionsDecisions that need more than one page, made once and kept for the whole document.
- §5
Layout
11 sectionsDividing a page into regions: what a block is, its class, its boundaries and its reading order.
- §6
Headings and page structure
11 sectionsTelling headings from labels, captions and furniture; folios, leaders, margin notes and contents pages.
- §7
Text
27 sectionsInline markup, and the marks a page carries: stamps, signatures, seals, redactions, watermarks.
- §8
Lists
1 sectionBullet markers and nesting.
- §9
Tables
39 sectionsWhat counts as a table, where one ends, and how its headers, columns, rows and cell values are written.
- §10
Forms
15 sectionsFields, blanks, checkboxes and option groups, written as key-value lines in printed order.
- §11
Charts
13 sectionsTurning a chart into a table of every data point, with printed values preferred over estimates.
- §12
Images and diagrams
8 sectionsPutting an image’s content into the text: transcription, a table, a diagram language or a description.
- §13
Other
2 sectionsChemical structures and music notation.
- Appendix A
Equivalent forms
1 sectionSituations where two renderings both conform.
- Appendix D
Quick reference
1 sectionEvery rule’s requirement on one page.
Reading a rule page
- The requirement, in RFC wording, with its status and scope.
- When it applies: how to recognise the situation, often with a sketch of the printed page.
- Each part of the rule, with its own examples beneath: the source page beside the expected output and the exact Markdown.
- Neighbouring rules, and why each one resolves differently.
- ✅ Normative
- Settled; the requirement holds as written.
- ⚖️ Equivalent forms
- Two renderings conform; a document uses one throughout. Marked 2 forms in the list.
- ❓ Open point
- Not yet settled; follow the working default. Marked open.
- 📚 Document rule
- Needs other pages of the document; decided once. Marked doc.
- ✅ Sample · ❌ Counter-sample
- The rule applies · it looks like it applies and does not, or a rendering got it wrong.