readable without renderingself-documenting commandsUnicode mathematicsdocuments for humans and machinessince 1972
Compose is a structured document language with self-documenting syntax and native Unicode mathematics. Developed at MIT and Honeywell between 1972 and 1985, it was extensively used to publish books and technical manuals. It is also an interactive terminal language. Recovered and extended by ｢｣ Lingenic.
Lingenic Compose is a unified system for creating documents and the letterforms they're set in, built on two recovered bodies of knowledge: the Multics document processing tradition (1972–1985) and the physical mark-making traditions that created the world's writing systems over millennia.
Compose unifies capabilities that typically require separate tools:
| Instead of | Compose provides |
|---|---|
| TeX-based typesetting | Native Unicode math and readable typesetting |
| Spreadsheet formulas | Inline calculations |
| Computational notebooks | Interactive documents |
| Lightweight markup | Professional typography |
Documents contain expressions, not results. Expressions render locally — no data center tool calls. This distributes compute: lower latency, offline-capable, energy-efficient, private.
Computation shifts from authoring (where humans and even AI models make arithmetic errors) to rendering (where math libraries compute correctly). A math textbook written in Compose has examples which are always freshly computed — never stale, never out of sync. Like charts in a spreadsheet, expressions stay in sync with their inputs.
A complete document preparation environment descended from Multics Compose — not a formatter in a toolchain (the Unix model), but a unified environment where the user never leaves the document (the Multics model). Formatting, computation, text processing, pattern matching, bibliography, input/output, and interaction are all native capabilities.
The inherited core was battle-tested for thirteen years. Lingenic preserved the design, removed the one hardware-driven compromise (terse command forms), and extended it with Unicode mathematics, style classes with media/interaction conditionals, domain-namespaced computation (math, symbolic, financial, statistics), block templates, bibliography with field access, and a tool-use protocol that emerged naturally from the 1975 terminal I/O model with a two-word extension.
Font formats, each modeling a different physical mark-making tradition through the tool that created it.
These are not outline font formats. They don't describe what letters look like — they describe how letters are made. A .字 file encodes brush entry angle, pressure variation, brush actions (press-pause, lift, sharp turn, round turn, twist), bristle type, ink concentration, and stroke connections — the vocabulary of Chinese calligraphic theory, expressed in that theory's own terminology. A .lapidary file encodes chisel profile, cut depth, approach angle, stone hardness, grain direction, and serif termination technique — the working knowledge of a Roman stonemason.
The .字 format accepts keywords in Traditional Chinese, Simplified Chinese, Japanese (old and new forms), Korean, and Vietnamese. A Chinese calligrapher writes .畫始 主 點 / 入鋒 露鋒 / 鋒法 中鋒 / 徑 500,850 輕重 0.4. A Japanese calligrapher writes the same thing in Japanese terminology. An English-speaking type designer writes .stroke-begin main dot / entry-style tip-exposed / tip-mode tip-center. All equivalent. The self-documenting naming principle applied across civilizations.
This is a taxonomy of human mark-making, not a software abstraction.
HyperMedia — documents as the interface. The Multics principle taken to its logical endpoint: if the user shouldn't leave the document for computation, text processing, or bibliography, they also shouldn't leave it for interaction, navigation, or input. .read with pattern matching handles forms. .when-click and .when-hover handle events. Links and history handle navigation. The document is the application.
Lingenic LLC has recovered the language from the Multics archives, preserved its complete command vocabulary and design philosophy, and extended it with block templates, style classes, Unicode mathematics (ISO 80000-2), domain-namespaced computation, and interactive capabilities. The project is open source under Apache 2.0.
In 1969, Bell Labs withdrew from the Multics project. Ken Thompson and Dennis Ritchie went on to create Unix, carrying with them a design philosophy that would define computing for the next half century: small tools, each doing one thing well, composed through pipes.
Multics took the other path: unified tooling, where the system provides everything the user needs in one environment. The user doesn't assemble a pipeline — the tool is complete.
This split is the lens through which Lingenic Compose makes sense. Compose is not a Unix-lineage tool. It does not do one thing well and expect the user to bring the rest. It is a Multics-lineage system — a unified document environment where formatting, computation, text processing, bibliography, input/output, and interaction are all native capabilities. The user never needs to leave the document to accomplish document tasks.
Every major document system in use today descends from the Unix side of the split. LaTeX requires a toolchain: pdflatex + biber + makeindex + latexmk + package manager + editor + previewer. Pandoc is a conversion tool in a pipeline. There are tools that try to be better than LaTeX — cleaner, faster, but still remain formatters that expect the user to bring computation, data processing, and interactivity from elsewhere.
Compose is the other lineage, recovered.
The core document language is not new — it was designed, implemented, battle-tested, and used in production for thirteen years. The command set covers professional typesetting comprehensively: page layout, fonts, margins, columns, headers and footers, footnotes, tables, indentation, hyphenation, fill and justification, widow and orphan control, keep blocks, change bars, literal mode, index generation, and fine-positioning down to centipoints (7200 per inch).
This heritage matters for evaluation. The specification reads as large (~200+ commands) because Multics Compose was a large, mature system — the size reflects thirteen years of production refinement, not speculative overdesign. The risk profile of the document language is fundamentally different from a system designed from scratch: the design decisions have already been validated by real use.
The defining characteristic inherited from Multics is systematic, self-documenting command names. Every command reads as an English instruction:
| Command | Meaning |
|---|---|
.begin-header | Begin a page header |
.break-page | Break to a new page |
.vertical-margin-top | Set the vertical margin at top |
.align-center | Align to center |
.begin-keep | Begin a keep block |
Related commands share vocabulary — knowing .vertical-margin-top exists suggests .vertical-margin-bottom, .vertical-margin-header, .vertical-margin-footer. This discoverability scales: the naming system remains navigable at 200+ commands because the patterns are consistent.
Compare to LaTeX (\frac, \hfill, \textbf, \makeatletter) or troff (.br, .sp, .in, .fi), where commands require memorization or documentation lookup. These are programmer tools — terse, efficient, opaque. Compose commands are user-facing — verbose, self-explanatory, discoverable.
Multics Compose offered dual forms for every command — terse (.bph) for expert operators working at 110 baud, verbose (.begin-header) for documentation and learners. Lingenic drops the terse forms as the canonical storage format, since the hardware constraint that justified them (keystroke cost at 10 characters per second) no longer exists.
The design is that editors may offer abbreviations as expanding input shortcuts, but documents always store the verbose canonical form. This means .compose files are readable without any tooling, diffs are meaningful in version control, and grep works against human-readable command names. Authoring convenience is separated from document representation.
Preserved: The complete command vocabulary, the naming philosophy, the typesetting model, the I/O system, the pattern matching — and the Multics principle of unified, user-focused tooling.
Removed: Terse command forms (the only hardware-driven compromise).
Added: Unicode mathematics, style classes with conditional application, domain-namespaced computation, block templates, bibliography with field access, accessibility primitives, font technology, tool-use protocol, HyperMedia architecture.
The inherited design didn't age poorly. The I/O model became a tool-use protocol with a two-word extension. The pattern matching provides text processing capabilities no modern document language offers. The self-documenting naming scales to every new domain spec. The accessibility model is correct by construction. These features weren't ahead of their time — they were from a different lineage that the industry abandoned when Bell Labs walked away in 1969 and Unix won.
The extensions are architecturally coherent with the Multics original — they follow the same naming philosophy and command structure, but address capabilities the 1970s system predates. Crucially, they maintain the Multics principle: the user shouldn't have to leave the document to accomplish document tasks.
Math expressions use Unicode symbols directly rather than escape sequences:
.begin-math 𝑥 = (−𝑏 ± √(𝑏² − 4𝑎𝑐)) / (2𝑎) .end-math
No \alpha, no \rightarrow, no \mathbb{R}. The symbols ∑, ∫, α, ℝ, → appear as themselves, per ISO 80000-2. Structural commands (.fraction, .matrix, .cases, .begin-math-align) handle layout; Unicode handles notation. The math is readable in source without rendering.
This is where the Multics philosophy — unified tooling for the user — meets modern requirements most clearly.
A user writing a finance textbook shouldn't need Python. A user writing a statistics paper shouldn't need R as a separate tool. A user writing a math textbook shouldn't worry about stale computed examples. Compose addresses this through domain-namespaced expressions that evaluate at render time:
| Domain | Purpose | Example |
|---|---|---|
math | Arithmetic, trig, log | %math(√(𝑥² + 𝑦²))% |
symbolic | CAS — integration, derivation | %symbolic(d/d𝑥 sin(𝑥))% |
financial | TVM, depreciation, bonds | %financial(payment 250000, 0.005, 360)% |
statistics | Distributions, descriptive stats | %statistics(mean 1, 2, 3, 4, 5)% |
Documents contain expressions, not results. A finance textbook with %financial(payment 250000, 0.005, 360)% computes the mortgage payment at render time. Change the principal, and every derived value in the document updates automatically. No stale numbers, no sync errors between formulas and examples. Like charts in a spreadsheet, expressions stay in sync with their inputs.
The financial domain alone covers time value of money, annuities (including due and perpetuity variants), five depreciation methods, bond pricing with duration and convexity, MIRR, discounted payback period, and ISO 4217 currency formatting — all with self-documenting function names like depreciation-double-declining and present-value-annuity-due.
Block syntax (.begin-math, .begin-financial) typesets expressions for display. Inline syntax (%domain(...)%) evaluates them. Same expression syntax, two purposes, clearly separated.
Extended domains (symbolic, financial, statistics) are optional — documents declare requirements with .require, and implementations provide backends (Maxima for CAS, R for statistics). The document specifies what computation it needs; the implementation provides how. But the user never leaves the document to invoke those tools — the document environment handles it.
Templates define reusable content structures with parameters. Styles define reusable formatting with conditional application:
.begin-define-style sidebar
padding-left = 12pt
background-color = #f5f5f5
.when-media print
border-left = 2pt solid #666
background-color = none
.end-when
.when-media screen
background-color = #e8f4f8
.end-when
.end-define
.when-media, .when-page, .when-first, .when-hover, .when-click — these are CSS media queries and pseudo-classes expressed in Compose's self-documenting syntax. This is genuinely new design that extends the Multics model into web and interactive contexts while maintaining stylistic coherence with the original. Multics Compose didn't have style classes, media conditionals, or interactive states — it targeted line printers and phototypesetters. The style system is a Lingenic innovation built on Multics principles.
In the Unix model, a user who needs to parse text leaves their document and reaches for sed, grep, awk, or a scripting language. In the Multics model, text processing is part of the document environment.
Multics Compose was always an interactive terminal language, not just a formatter. It had .read for input, .type for output, variables, conditionals, and loops. Lingenic extends the pattern matching with character classes, alternation, wildcards, and capture groups:
.begin-read %Mr|Mrs|Ms|Dr% %name% .end-read
.translate "%[0-9][0-9]%/%[0-9][0-9]%/%[0-9][0-9][0-9][0-9]%" "%1%-%2%-%3%"
This is structurally equivalent to what languages like Rust, Elixir, and Haskell provide as pattern matching, applied to text processing in a document context, designed in the 1970s. Combined with .translate for pattern-level substitution, Compose is a text processing language — documents can parse, extract, transform, and validate data during typesetting. No modern document language has this capability natively, because modern document languages descend from the Unix side of the split where text processing is a separate tool.
The original terminal I/O model has been extended with tool integration: .begin-type "tool" "id" sends structured output to an external system; .begin-read "id" reads the response. The 1975 interaction pattern (structured output to an external actor, structured input back) is isomorphic to a 2026 tool-use protocol. The design was already correct — only the vocabulary of what it talks to has changed.
The spec's framing: "Semantic structure is implicit in commands. These additions provide what only authors can supply."
Because .title declares content as a title (not "make this text large and bold"), and .begin-footnote declares a footnote (not "small text at the bottom"), the command structure is inherently semantic. A screen reader or document converter can derive structure directly from commands without a separate accessibility layer.
The explicit accessibility additions are deliberately minimal — just three commands for the things only a human author can provide: alt="description" for images, .language for language switching, and .abbreviation for acronym expansion. Everything else is inferred from the document structure that already exists.
This is accessibility as a design consequence, not a compliance checklist.
Citations support CSL styles and direct field access via dot notation:
%cite: knuth1984 page=42% → (Knuth, 1984, p. 42) %knuth1984.title% → The TeXbook %knuth1984.author% → Knuth, Donald E.
Formatted citations and raw field access from the same source definitions, with seven built-in citation styles and custom CSL file support. In the Unix model, bibliography management is a separate tool (bibtex, biber). In Compose, it's part of the document.
The HyperMedia system is Lingenic's vision for the full Multics-philosophy endpoint — interactive document rendering where the document is the environment:
The concept: documents as the interface, where .read with pattern matching handles forms, .when-click and .when-hover handle interaction, and navigation links documents together — without a DOM, without CSS, without JavaScript. Not an app platform. Not a web page. A document-centric environment where content, computation, and interaction unify.
The comparison to HyperCard is apt. HyperCard was "documents as applications" and was enormously productive precisely because it didn't require users to think in terms of application architecture. Compose makes the same bet, with fifty years of document-processing design underneath it.
Lingenic is building font technology from first principles, modeling letterforms through the physical tools that historically created them:
| Library | Tool Model | Font Format |
|---|---|---|
pen-path | Broad-nib pen (Western calligraphy) | .lettering |
brush-path | Brush (Chinese calligraphic theory) | .字 |
chisel-path | Chisel/V-cut (Roman inscriptions) | .lapidary |
engraving | Burin/graver (copperplate) | .engraving |
All implemented in Rust. Rather than storing outline contours (TrueType/OpenType), these formats describe the process of mark-making — tool, stroke, pressure. This enables parametric font generation, stroke-order animation, and cultural fidelity (CJK characters modeled through brush theory rather than Western outline conventions).
This too follows the Multics principle: the user shouldn't need a separate font tool. The font technology is part of the system.
TeX won by distribution, not design:
Every one of these disadvantages is now gone. In 2026, Compose is open source, runs in a browser via the JS renderer, requires no mainframe, and costs nothing.
But the more important point is that TeX and Compose represent different philosophies, and TeX's victory was also the victory of the Unix model: the document tool does formatting, and everything else is someone else's problem. Compose's recovery represents the possibility that the other model — unified, user-focused, document-as-environment — may still have something to offer.
| System | Lineage | Philosophy |
|---|---|---|
| LaTeX | TeX → Unix | Formatter in a toolchain |
| Pandoc + Markdown | Unix pipeline | Conversion tool in a pipeline |
| groff/troff | Unix | Formatter |
| Compose | Multics | Unified document environment |
Compose's differentiation is not a feature comparison — it's a paradigm difference. Every competitor is a Unix-lineage tool that does one thing (formatting) and expects the user to assemble the rest. Compose is a Multics-lineage environment where the document handles formatting, computation, text processing, bibliography, input, output, interaction, and navigation as integrated capabilities.