General

This document is the third document of the Plurimath specifications series. It specifies the format interfaces: the readers that turn text and markup in each supported notation into the formula tree, the writers that turn the tree back out, the error behaviour at each boundary, and the round-trip properties that connect them.

The interfaces described here are implemented in the plurimath gem of the 0.11 series. Where this document and the implementation disagree, the disagreement is a defect in one of the two.

Documents in the series

Maintainers

This document is maintained by the Plurimath project at https://github.com/plurimath/plurimath.

1.1  General

This document specifies the format interfaces of the Plurimath system:

This document does not specify:

1.2  Relationship to the series

1.3  Audience

Implementers of Plurimath, authors of independent readers or writers that must interoperate with it, and applications embedding the system.

1.4  The interface inventory

Every interface reads or writes the one tree of PM 1001; none of them defines content of its own.

4.1  General

Interface signatures are written as parse(text, type, **options) and to_<format>(options) following the implementation’s shape; this document specifies behaviour, not a language binding. Format names follow PM 1001.

4.2  Examples

Examples carry an Expected outcome paragraph stating observable behaviour. Where an example shows reading, the outcome states the resulting tree; where it shows failure, the typed error and its message shape.

4.3  Normative encodings

The encodings read and written here are the ones defined in PM 1001 (surfaces) and PM 1002 (uncertainty); this document adds the reading rules, not new encodings.

4.4  Corpus entries

Where an example says “the corpus freezes” an outcome, the frozen vector is the example with its provenance; the corpora are external, versioned artifacts, and this document’s examples are their illustrations.

5.1  General

Every exchange with the outside world passes one of two boundaries:

lml "1.0"

models FormatInterfaces {

  class Reader {
    attribute accepted_type, TypeKey[1]
    attribute input, String[1]
    attribute options, ParseOptions
  }

  class Writer {
    attribute surface, SurfaceKey[1]
    attribute tree, Formula[1]
    attribute options, WriteOptions
  }

  enum TypeKey {
    value asciimath
    value html
    value latex
    value mathml
    value omml
    value unicode
    value unitsml
  }

  enum SurfaceKey {
    value asciimath
    value html
    value latex
    value mathml
    value omml
    value unicodemath
  }

  class ParseOptions {
    attribute locale, String
  }

  class WriteOptions {
    attribute display_style, Boolean
  }
}

A reader receives text of one accepted type and yields a formula tree. A writer receives a tree and emits one surface’s bytes. Neither boundary exposes anything else: no parser objects, no intermediate representations, no partial trees.

5.2  The boundaries are typed

Every failure crossing a boundary is a typed error (Annex A). A reader that cannot complete raises a ParseError or one of its specialized subclasses; a writer does not fail on a well-formed tree — render totality is a model guarantee of PM 1001 — and the renderer’s failures are the rendering errors of clause 13.

5.3  Composition

The interfaces compose without glue: the tree a reader yields satisfies every writer. An application may read AsciiMath, inspect the tree, evaluate it (document 1004), and write OMML in one pipeline; no format-specific steps exist between the boundaries.

5.4  Boundary invariants

Four invariants hold at both boundaries, and the clauses that follow make each precise:

5.5  Where the units reader sits

The unitsml type is a reader without a writer: it reads one unit expression (CalConnect 36817) into the unit embedding the tree carries. It exists so applications can validate and embed units independently of a surrounding formula, and its failure mode is the parse error naming the unit expression.

5.6  The contracts as obligations

The two boundaries carry symmetrical obligations, which the rest of this document discharges:

An implementation audit walks these two tables; the conformance classes of clause 15 are their operational form.

6.1  The parse entry point

Reading goes through one entry point, parse(text, type, **options):

The entry point never raises any other error. An internal exception escaping a reader is a defect of the reader; the boundary converts everything it can into the typed errors and preserves the specialized ones unchanged.

6.2  Accepted types

The localized types accept the locale option, which selects the language-specific readings of symbols and function names (for instance, localized function names in LaTeX and HTML inputs). The markup types do not localize: a MathML document says what it says.

6.3  The tree guarantee

A reader yields a tree that satisfies PM 1001: node classes from the model, operands in the class-defined order, no formatting in descendant nodes, and — for inputs carrying uncertainty encodings — uncertainty nodes per PM 1002. A reader never yields a tree it cannot itself render.

6.4  The input string

The yielded tree records the input text verbatim. Diagnostics, error messages and the math zone printers may show it; the tree’s identity does not depend on it: two trees read from equal inputs carry the same input_string and are equal; two equal trees from different inputs differ only in that field.

6.5  Failure

A reader’s refusals are part of its contract. The general ParseError names the input and the type; the specialized errors name their cause: an ambiguous decimal in uncertainty reading raises AmbiguousDecimalError, a missing parsing dependency raises MissingDependencyError. The message shapes of Annex A are stable within an edition.

6.6  Validation order

The entry point validates in a fixed order, so callers can predict which error they see first:

A call with both an unknown type and an unknown option reports the type. A call with a bad option and a malformed input reports the option. No reader runs before the boundary checks pass.

6.7  What each reader guarantees

Every reader, for every input it accepts, yields a tree with these properties:

The last property keeps trees portable: a tree does not remember which reader made it, and PM 1001’s syntax-independence invariant holds at the boundary.

6.8  Reading is not interpretation

Readers translate structure; they do not evaluate, simplify, reorder or repair. An input that says 2 + 2 yields a tree that says 2 + 2; whether that is 4 is evaluation’s business (document 1004). An input with a suspicious construct — a division by a zero-valued expression, an inverted interval — reads as written; the evaluators and the checkers flag, the readers transcribe.

6.9  Reading uncertainty: the summary

The reading rules per format, in one place (the full rules are PM 1002’s encodings plus the clauses above):

A marker and its shape disagreeing is a producer defect; the reader takes the marker, and the next write emits a consistent pair. The corpora include a stale-shape vector per markup format so the authority is tested, not stated.

7.1  Entry points

A tree writes to each surface through one entry point: to_asciimath, to_mathml, to_omml, to_latex, to_unicodemath, to_html. The surfaces, their outer elements and their stability rules are PM 1001’s; this document adds the interface obligations.

7.2  Determinism

Writers are deterministic and byte-stable per PM 1001. This document adds: a writer emits only through its own boundary — no writer depends on a reader having produced the tree, and no writer consults the tree’s input_string.

7.3  The display-style option

The root’s display flag (PM 1001) may be forced per call: a writer asked for display style renders the display form regardless of the root’s flag, and one asked for inline renders inline. Absent an override, the root’s flag decides.

7.4  Failure

A writer given a well-formed tree does not fail. A writer given a tree that violates PM 1001 — an operand missing, an unknown node class — is outside the contract; implementations report it as a programming error, not as a parse or rendering error.

7.5  Family obligations per surface

The writers’ family obligations, at the level this document pins them (the per-construct detail is PM 1001’s mapping and PM 1002’s encodings):

Every cell is discharged by the corpora: each family’s row in each surface’s column has corpus vectors, and a writer claim covers its column end to end.

7.6  Writing what was not read

A tree may be built by construction — an application assembling nodes — rather than by reading. Writers treat constructed trees identically: the boundary knows no difference between a read tree and a built one. This is what makes evaluation pipelines possible: document 1004’s output trees write like any others.

7.7  Idempotence of shape

Writing a tree twice yields identical bytes. Writing a read-back tree yields the same bytes as writing the original: the round-trip property plus writer determinism give write-read-write idempotence per lossless format. The corpora assert it.

8.1  Reading

The AsciiMath reader accepts the linear form: symbols and function applications of the registry vocabulary (PM 1001), grouping, scripts, fractions, nary constructions, text in text(...) and in quoted strings, and the uncertainty forms of PM 1002.

The quoted string is content: "unitsml(kg*m/s^2)" is the UnitsML channel, read as a unit embedding; any other quoted string is upright text. The reader does not interpret inside a quoted string beyond the UnitsML channel check.

The uncertainty reading follows PM 1002:

8.2  Writing

The AsciiMath writer emits per PM 1002’s encodings: the calls with their argument orders, the concise reporting form for concise nodes, the quoted UnitsML channel for expressible units and the visible unit otherwise.

8.3  Losslessness

The AsciiMath interface is lossless: writing a tree and reading the result yields an equal tree, for every tree the model defines. The one deliberate asymmetry: a concise node writes the reporting form and reads back concise — the notation survives the round trip, as a field of the node.

8.4  The accepted surface

The reader accepts the construct families below, in the spellings of the registry vocabulary. The table states each family’s AsciiMath shape and the node it yields; the vocabulary itself is the registry of PM 1001.

8.5  Precedence and grouping

The reader applies the notation’s precedence: scripts bind tighter than adjacency, fractions tighter than addition, and explicit grouping overrides. The tree is the precedence-correct reading; an author who means something else parenthesises. This document does not restate the precedence table — the reader’s behaviour is its definition, and the corpus pins it vector by vector.

8.6  Localization

The localized symbols and function names follow the active locale: an Italian locale reads sen as the sine function where an English reading sees a symbol sequence. Localization affects which tokens map to which nodes; it never changes the tree shape a construct yields.

8.7  Errors and the corpus

The reader’s refusals are pinned by the corpus alongside its successes: every reading error of Annex A that the AsciiMath surface can produce has a corpus vector whose expected outcome is the error and its message shape.

8.8  The quoted channel, precisely

A quoted string in AsciiMath input is content, with exactly one special case: text matching the UnitsML channel shape unitsml(<expression>) becomes a unit embedding. The check is on the whole string, after trimming nothing: " unitsml(g)" with a leading space is text, "unitsml(g)" is the channel. Anything inside the channel that the unit reader refuses is a reading error naming the expression — the channel never silently degrades to text, because a unit intended as a unit must not become prose.

8.9  Concise reconstruction, precisely

On reading the reporting form v(digits):

A digit string that cannot be reconstructed at the value’s place count — more digits than places is unambiguous, fewer or mismatched is not — raises AmbiguousDecimalError. The reconstruction never invents places: 10(2) reads magnitude 2 at zero places; 10.3(25) refuses.

8.10  Symmetric, precisely

The AsciiMath kind token symmetric reads to probabilistically-symmetric before node construction; the model never sees the short spelling. Writing a probabilistically-symmetric node emits symmetric in AsciiMath and the full name everywhere else. The asymmetry is spell-level and pinned in both corpora.

8.11  AsciiMath error table

8.12  Writing matrices and alignment

The table classes write in the bracket forms; Align and Eqarray write with the ampersand alignment their reads accept. Alignment points are structural for these classes and survive the round trip; a writer that drops them fails the corpus.

8.13  The vocabulary surface

The AsciiMath reader’s symbol vocabulary is the registry’s AsciiMath token set. The families, with representative tokens (the full set is the registry; the corpus exercises it):

Function-name tokens follow: sin, cos, tan and kin, log, ln, lg, exp, min, max, gcd, lcm, mod, det, dim, deg, exp, hom, ker, lim with its variants — each reading to its function class. Locale-selected alternatives exist for a number of them, per clause 6.

8.14  Text and quotes, precisely

text(...) reads its content as upright text with grouping; quoted strings read as text with the UnitsML channel exception of this clause. The two forms differ in one observable way: text(...) may contain AsciiMath commands, a quoted string never does — quotes are literal, which is what makes them the right channel for content a formula must not interpret.

8.15  What the corpus pins for AsciiMath

The AsciiMath corpora carry, at minimum: every registry family with a representative per entry-group; every construct family of the table above, in plain and grouped forms; the uncertainty forms of PM 1002 with all categories, notations and kinds; the quoted channel with expressible, inexpressible and refused units; the localization pairs; and the error table’s rows. 143 cases formed the first frozen generation; later generations extend, never rewrite.

9.1  Reading

The MathML reader accepts a MathML 4 document or fragment. It reads the presentation markup into the tree: mi, mn, mo, mrow, mfrac, msqrt, mroot, scripts, tables, and the constructs the model names. Two rules govern semantics:

Unknown presentation elements are read as their content where they are containers and refused where they are not: the reader does not silently drop structure it cannot represent.

9.2  Writing

The MathML writer emits MathML 4 per PM 1001’s surface rules: mathvariant from font styles, intent markers from uncertainty nodes, mtable families from tables, mn/mi/mo per the registry entries. The display attribute follows the root’s flag or the call’s override.

9.3  Losslessness

MathML is lossless for the constructs the model defines, with the intent-authority rule for uncertainty. A MathML document using constructs the model does not define reads to the closest model content it can represent and records nothing else — such documents are outside the losslessness claim.

9.4  Element mapping

The reader’s element mapping, at family level:

9.5  Whitespace and mspace

Significant whitespace in MathML is structural; the reader treats mspace per its width semantics and collapses presentation-only whitespace, as MathML itself prescribes. Trees carry structure, not spacing.

9.6  Diagnostics

A MathML input that mixes constructs the model cannot represent reads to its representable core; the reading corpora contain such vectors with their expected trees, so the boundary between “reads with loss” and “refuses” is pinned, not folklore.

9.7  Reading algorithm

The MathML reader walks the document in order:

9.8  The intent-authority consequence

Because markers are authoritative, a MathML producer has exactly one way to be wrong about uncertainty: emit a marker whose arguments contradict the visible content. That document reads to the marker’s fields. A producer that wants the visible shape to win must not carry a marker; but then the node is not an uncertainty node, and the shape reads as ordinary constructs.

9.9  Entities

Named entities (&#x3b1;) and numeric character references read through the registry’s MathML renderings — an entity the registry knows reads to its entry; an unknown entity is a reading error naming it.

9.10  Writing the intent, concretely

The uncertainty markers of PM 1002 write as the intent attribute value on the enclosing mrow: intent="standard-uncertainty(10.3,0.2)". The attribute is the whole machine-readable contract; a MathML consumer that understands intent reads the fields, one that does not sees the shape. The writer never splits a marker across elements or abbreviates it — the grammar of PM 1002 is the attribute’s entire alphabet.

10.1  Reading

The OMML reader accepts DrawingML mathematics (ECMA-376, m: namespace): runs, run properties, fractions, radicals, scripts, nary constructs, matrices, delimiters, and phantom boxes.

The marker convention is authoritative for uncertainty: a run holding an uncertainty marker string (PM 1002’s grammar) marks the construct that follows; the fields come from the marker and the shape runs are regenerated. A consumer that never learned the convention sees one extra run of text; a conforming reader consumes it.

Run properties map to font styles; m:nary to the nary classes with their character; matrices to the table classes; m:d delimiters to Fenced. As with MathML, structure the model does not define is read to its closest representable content.

10.2  Writing

The OMML writer emits per PM 1001: run properties from font styles, m:nary from nary nodes, m:m matrices with the table class’s delimiters, m:d from fences, and the marker run before the shape runs for uncertainty nodes, with the unit boxed. The display form wraps in m:oMathPara per the root’s flag.

10.3  Losslessness

OMML is lossless for the model’s constructs under the marker-authority rule.

10.4  Construct mapping

10.5  The marker run in detail

The marker run is an ordinary m:r whose text matches PM 1002’s marker grammar. The reader scans for it at the start of a construct it marks; on a match, the construct’s fields come from the marker and the shape runs are skipped. A run that resembles a marker but is ordinary text — inside another run, or after the construct it would mark — is text. The convention is positional: marker first, shape after.

10.6  Run properties

Fonts, styles and script positioning in run properties map to the font style nodes and the script placement the model defines; properties without a model counterpart (kerning, colour) are dropped on read, as presentation the tree does not carry.

10.7  Reading algorithm

The OMML reader walks the m: tree:

10.8  OMML specificity of the model

Two OMML constructs have model-specific treatment: pre-sub/superscript (m:sPre) reads to Multiscript, and the equation-array constructs read to Align/Eqarray with their alignment. Everything else maps one to one.

10.9  Writing matrices and nary constructs, concretely

The table classes write to m:m with delimiter properties per class: Matrix plain, Pmatrix parenthesised, Bmatrix braced, Vmatrix barred, Cases with the asymmetric brace. The nary classes write to m:nary with m:chr carrying the character and the limits in m:sub/m:sup; a limit absent leaves the element empty rather than omitted, which is how OMML spells “no limit here”.

11.1  Reading

The UnicodeMath reader accepts the linear format of UTR #28 as the implementation defines its surface: symbols, fractions, scripts, nary constructs, and the intent wrapper ⓘ("marker" visible).

The wrapper is authoritative for uncertainty: the marker string inside the quotes carries the fields; the visible shape inside the wrapper is regenerated. The ⓐ(unit ...) form inside the wrapper carries the unit. Outside wrappers, the linear format reads per its own conventions — ^, _, / grouping, named symbols from the registry’s UnicodeMath tokens.

11.2  Writing

The UnicodeMath writer emits per PM 1001 and PM 1002: the linear forms of the constructs, the intent wrapper for uncertainty nodes with the marker and the regenerated visible shape, and ⓐ(unit ...) for the unit.

11.3  Losslessness

UnicodeMath is lossless for the model’s constructs under the intent-authority rule.

11.4  Token families

11.5  The wrapper is the only comment channel

UnicodeMath has no comment or annotation mechanism the model carries; the ⓘ wrapper is the single channel for machine-readable intent. An ⓘ whose quoted text does not match the marker grammar is a reading error, not text — the wrapper is reserved.

11.6  Linear-format precedence

As with AsciiMath, the reader applies the linear format’s precedence and the corpus pins it. Fraction and script grouping in parentheses follows UTR #28’s conventions as the implementation defines them.

11.7  Reading algorithm

The UnicodeMath reader scans the linear text:

11.8  Why the wrapper skips and regenerates

The visible shape inside a wrapper was produced from the marker’s fields; re-reading it would invite the stale-shape problem the marker exists to prevent. The reader reads the marker, reconstructs the node, and moves past the visible shape.

12.1  LaTeX

The LaTeX reader accepts the fragment-level LaTeX the writer emits, plus the common mathematical core: commands of the registry vocabulary, environments for tables and alignment, and math-mode grouping. It does not accept document preamble, packages or free text outside math.

LaTeX is a lossless direction for the model’s constructs: writing and reading returns an equal tree, with the exceptions the registry records (constructs whose LaTeX rendering is approximate carry the approximation in both directions and are equal as trees).

The LaTeX writer emits per PM 1001 and PM 1002, with the statements of PM 1002 after the unit.

12.2  HTML

HTML is a display surface. The writer emits an HTML fragment optimised for browser presentation: nested elements for structure, sub/sup for scripts, and the encodings of PM 1002 for uncertainty. HTML does not read: the interface has a writer only, and round-trip claims do not include it.

12.3  Command mapping

12.4  What the LaTeX reader refuses

Preamble, \usepackage, document environments and free prose between math are refused: the interface is a math fragment interface. A document that carries formulas in prose extracts the formulas first; that extraction is outside this interface.

12.5  The HTML writer’s output shape

The HTML writer emits nested presentational elements: spans for structure, sub/sup for scripts, fraction layouts with borders, tables for matrices, and the statement spans of PM 1002. Class names are stable within an edition and the corpus freezes them.

12.6  An HTML fragment, concretely

The HTML writer’s shape, for the power example of PM 1001:

<span class="plurimath-formula"><i>x</i><sup>2</sup></span>

The class names are the writer’s stable surface: editions may add classes, never rename them. Presentational decisions (fonts, sizes) belong to the host page’s styles; the fragment carries structure and semantics only.

12.7  LaTeX shape, concretely

The same tree in LaTeX:

x^{2}

and the quadratic formula:

x = \left(-b \pm \sqrt{b^{2} - 4ac}\right)/(2a)

The writer emits the linear fraction form when the tree was read from one and the \frac form when built as Frac; both read back to equal trees, and the round-trip corpus carries both shapes.

13.1  The renderer

Beyond the text surfaces, a tree renders to images — SVG, PNG, PDF and PostScript — through the optional renderer, which delegates to the lasem library. Rendering goes through one entry point, render(text, type, format:, **options): it parses per clause 6 and renders the parsed tree to the requested image format.

13.2  Availability

Image rendering is available when the lasem gem and its native extension are present; it is never available under Opal. Availability is queryable and never raises: render_available? answers the question, and render raises the typed errors when called without it.

13.3  Failure

The renderer’s failures are typed: RenderingUnavailable when the library is missing, UnsupportedRenderFormat for a format it does not offer, RenderingFailed when rendering fails on a tree that parsed. Parsing failures surface as the parse errors of clause 6 — the renderer never masks a parse failure as a rendering failure.

13.4  The rendering pipeline

Rendering composes two boundaries: parse per clause 6, then render the tree to the image format through the library. Options split the same way — parse options to the parse step, the rest to the renderer. The pipeline is one entry point so that callers cannot interleave a broken state: either the image bytes or a typed error, nothing in between.

13.5  Formats and their properties

The corpus freezes one image per format at a reference size; raster differences at other sizes are not drift.

13.6  Availability and platforms

The renderer’s availability follows the library’s platform support: native where the extension builds, absent under Opal and on platforms without the native stack. Applications probe availability once and degrade to text surfaces where images are unavailable; the interface makes degradation explicit rather than failing mid-document.

13.7  Rendering and the model version

Image output depends on the library’s rendering of the intermediate form; it is byte-stable per model version plus library version, and the corpus records both. A library upgrade that changes bytes is a corpus regeneration with provenance, the same discipline as any other byte change.

14.1  The lossless directions

The lossless directions of the system:

A round trip composes the writer and the reader of one format: read(write(tree)) equals tree, under the structural equality of PM 1001, for trees built from the model’s constructs. The input_string after a round trip is the written form, not the original — identity of trees does not depend on it.

14.2  What survives

Every model field survives every lossless round trip: operands, order, uncertainty categories, fields, notation, interval kinds, units, intent annotations. The encodings of PM 1002 were designed so that no lossless format is the weak link: each carries the marker or the call that reconstructs the node.

14.3  What does not

Three things do not survive, by design and stated here so that no one searches for them:

14.4  A worked round trip

Start from the tree of Result two of PM 1002’s Annex D: the expanded uncertainty 10.3 g, U = 0.5 g (k = 2, p = 95%).

Expected outcome. after each lossless leg the tree is equal to the original in every field; the input_string differs at every leg, and identity is unaffected.

14.5  Round trips through different formats

Reading one format’s output with another format is not a round trip; it is two round trips joined by the tree. The composition works because every reader yields model trees and every writer consumes them: AsciiMath in, OMML out, OMML read, HTML out — each boundary checks per its own clause.

14.6  The corpus and the claim

The round-trip corpora freeze, per format: a spread of trees covering every node family, the uncertainty categories, units, and the registry’s approximate-rendering cases. A conforming implementation replays them all; one failure is nonconformance.

15.1  General

Conformance to this document is claimed per interface class. Every claim is discharged by replaying frozen vectors; nothing here is satisfied by assertion.

15.2  Conformance classes

A read-<format> claim carries the model claim of PM 1001; a roundtrip-<format> claim carries both directions’ claims.

15.3  The corpora

The reading corpora are frozen sets of inputs with frozen trees; the round-trip corpora are frozen trees replayed through write and read. Entries state provenance and never change within an edition.

15.4  Drift

A reader that yields a tree differing from the corpus for the same input does not conform. A writer whose bytes differ from the render corpus does not conform at the corpus’s model version. Drift is resolved by fixing the implementation or moving the model version, and recording which moved.

15.5  Claiming

A conformance claim names its classes, the model version, and the corpus generation. A claim without a corpus generation is not checkable and is not a claim.

15.6  Independent implementations

The contracts are written for more than the reference implementation: an independent reader that yields model trees per clause 6 and passes the reading corpora conforms, whatever its internals. An independent writer that passes the byte corpora conforms, whatever its codegen.

15.7  The error corpus

The typed errors are part of the contract and carry their own vectors: each error class has corpus entries whose expected outcome is the error with its message shape. An implementation that succeeds where the corpus expects a refusal does not conform — refusals are behaviour, not friction.

15.8  Corpus provenance

Claims name the generation they were checked against; a claim against generation N is void for generation N+1 until rechecked. The validator of the register build enforces the naming.

16.1  General

These are the only errors that cross an interface boundary. Message shapes are stable within an edition; the messages carry the input, the type, or the field responsible.

Specialized parse errors are subclasses of ParseError: an implementation catching ParseError catches them all, and one catching the subclass catches the specific case.

16.2  What never escapes

Parser internals, XML library exceptions, encoding errors and assertion failures never cross a boundary as themselves: a reader converts them to ParseError with cause information retained for diagnostics. A boundary that leaks a foreign exception is nonconforming.

17.1  Parse options

The locale value follows the implementation’s locale keys. A locale the implementation does not know raises ParseOptionError — silently ignoring a locale would read the wrong language and report success.

17.2  Write options

17.3  Rendering options

Unknown options at any boundary raise the typed option error; no boundary guesses.

17.4  Worked option cases

18.1  Reading (classes read-*)

18.2  Failure (all readers)

18.3  Round trips (classes roundtrip-*)

18.4  Image rendering (class render-images)

18.5  Boundary behaviour (all classes)

18.6  Localization vectors (localized readers)

18.7  Uncertainty reading vectors (classes read-*)

18.8  Vocabulary vectors (classes read-asciimath, read-unicodemath, read-latex)

18.9  Structure vectors (classes read-*)

18.10  Writer idempotence (classes write-*)