# VMPrint: a layout engine that ends where the math ends

> VMPrint is a pure JavaScript typesetting engine that treats document layout as a deterministic simulation over a persistent world, and hands back a flat array of glyph and box coordinates instead of a rendered page. It is aimed at Canvas and WebGL applications, high volume PDF generation and edge runtimes.

**cosmiciron/vmprint** — This layout engine can solve the hardest layout problems imaginable. Its output is DTP grade and deterministic. It's faster than engines written in C++ because it's not traditional. Backed by game engine tech, it has a microkernel and runs a spatial-temporal simulation instead of a giant complex pagination loop.

- Repository: https://github.com/cosmiciron/vmprint
- Website: https://cosmiciron.github.io/vmprint/
- Stars: 676 · Forks: 30
- Language: JavaScript
- License: Apache-2.0
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/cosmiciron-vmprint

## What the engine produces, and what it refuses to do

The README spends its first paragraphs drawing a boundary, and that boundary is the product. VMPrint is a layout engine, not a PDF library and not a renderer. Its job is the component that decides where every glyph goes, negotiates page breaks, resolves mutual spatial dependencies between dynamic regions, and produces a flat array of exact X and Y coordinates for every box and text run in the document. What you do with that output is described as your call: render to PDF, replay on a Canvas, drive a word processor display layer, or feed it to a WebGL pipeline. The engine's job ends when the math is done. That is a narrower promise than most document libraries make, and it is the reason the project can sit inside a rendering stack you already own rather than replacing it. It also explains the debug mode, which renders the same document with every actor boundary, margin and box labelled, because the layout is fully inspectable data rather than a drawing you have to take on trust.

## Pages as projections over a world, not containers for content

The core idea, as the README states it, is that document layout is a deterministic spatiotemporal simulation rather than a pipeline, and the README insists this is a literal execution model and not a metaphor. Document elements are described as autonomous actors inhabiting a persistent world coordinate space. Pages are viewport projections over that world, not containers that content gets assigned into. Actors negotiate geometry with their neighbours, publish committed facts when their placement settles, and other actors observe those facts and respond, all inside a single forward simulation pass. The output is captured when the world reaches equilibrium. The practical consequence is the claim the README leads with: things that need multiple passes in every other system, such as a table of contents that needs accurate page numbers, or a dynamic region that depends on sibling geometry, resolve correctly in one pass. The architecture is backed by a pending patent, which is worth knowing before you build a product on top of it, and it is also the reason the repository is organised around an engine core rather than around a document format.

## A table of contents that knows the page numbers on the first pass

The single pass table of contents is the clearest demonstration of the model, and it is worth working through the circularity it removes. A table of contents must know the page numbers before it can render, yet the page numbers of the content that follows depend on how much space the table of contents itself occupies. The README states that every prior system resolves this through a second layout pass, an approximation, or external auxiliary files, and that VMPrint resolves it in one pass. The mechanism is the committed signal. Heading actors emit committed signals as their geometry settles, and the table of contents actor observes those signals within the same running simulation and assembles accurate entries, so the numbers are exact and there is no second pass. The same argument extends to indexes and bibliographies. For a document tool this changes the shape of the problem, because a page number is no longer a value you have to guess and then re-derive, it is a fact that arrives in the same run as the geometry that produced it.

## Mixed script layout without HarfBuzz, ICU or a binary

The second structural decision is the absence of native dependencies. The README states that VMPrint provides multi script and bidirectional layout without an external shaping engine, with no HarfBuzz, no ICU and no system level binary, and that Arabic, Hebrew, Thai, Devanagari, CJK and Latin can sit on the same line, each script segment measured against its own font metrics, bidi reordered and baseline aligned against the dominant line metrics, in pure JavaScript. The engine is described as pure TypeScript with no native shaping dependency and no binary requirement, and it runs in a V8 isolate. That has two consequences. The first is deployment: the project names Cloudflare Workers, Deno Deploy and Lambda@Edge as environments where headless Chrome is impossible, because there is no subprocess, no tight bundle problem and no native binary story. The second is a capability limit, and it is real. Doing shaping in JavaScript means the font metrics handling and the script specific rules live in your runtime rather than in a heavily tested native library, so the correctness of Arabic and Thai layout in a given document is something you should inspect rather than assume.

## Update tiers, speculative branches, and atomic rollback

Two mechanisms handle change, and they are the parts of the engine a tool builder cares about most. The first is the update classification. When something like a page counter changes from 11 to 12, prior layout systems respond by recalculating layout, partially or fully. VMPrint classifies actor update outcomes into three tiers, no change, content only, and geometry changing, so a counter that changes its displayed number pays only the in place redraw cost and nothing downstream is touched. The second is deterministic speculative layout with rollback. Widow and orphan control, keep with next rules and cohesion policies are evaluated by placing a speculative branch, scoring it against the continuity policy, and then either committing or rolling back to a bit for bit identical kernel snapshot. The README is specific about what the rollback restores, listing active actor state, signal bus staging buffers and world space coordinates, and calls the rollback atomic and complete. That is the property that makes speculation safe, and it is the reason the same document always paginates the same way, page 42 is page 42 on every machine, every operating system and every run.

## Where it fits against a headless browser pipeline

The README names its audiences and, in doing so, names the alternative it is built to replace. For high volume report generators, the default approach is spinning up headless Chrome through Puppeteer, and the README describes the cost of that route: a full browser process per worker, roughly 300 MB of RAM, hundreds of milliseconds of cold start overhead, subprocess privilege, and cost that scales linearly with concurrency. VMPrint instead runs inside an existing Node.js process or V8 isolate, and the README gives its own figures, stating that 326 pages warm takes 718 ms with no browser and no subprocess, and showing a 324 page manuscript compiled from Markdown to PDF end to end in 2.32 s. Those are the project's own numbers, so treat them as a claim to test rather than a measurement. The other audiences are Canvas and WebGL tool builders, who have abandoned the DOM and need a typographic microservice, print on demand and automated publishing pipelines, where CSS page rules and break inside rules are described as unreliable across browsers, word processor builders who need inspectable layout data instead of contenteditable, and edge runtimes where a browser is not available at all.

## A workspace of many packages, and what to verify first

The repository is a private npm workspace named vmprint-workspace, and the package list in the root package.json is the clearest map of the system. The workspaces cover contracts, engine, cli, pressrun, preview, and globbed directories for contexts, font managers and transmuters. The build script chains the workspace builds in dependency order, starting with contracts, then the markdown core, the standard, local and web font packages, the canvas and two PDF contexts, the engine, the preview and the CLI, and finally a long tail of document contexts for academic work, literature, manuscripts, screenplays and Chinese manuscripts. There is also a sync script for the shared engine, node scripts/sync-shared-engine.mjs, with a check mode, and a shared engine workflow document in the repository root, which suggests the engine source is deliberately kept in one place and mirrored. The top level also holds a quick start, a changelog, a contributing guide and a documents directory that appears to hold the sample assets. The licence is Apache-2.0, which is permissive for commercial use, and the release history shows v1.0.0 in March 2026 and v1.4.0 in May 2026, with the last push on 2026-08-29.

## Conclusion

VMPrint fits a team that has already abandoned the DOM, or that cannot afford a headless browser per worker, and that needs deterministic, inspectable layout data for canvas rendering, bulk PDF generation or an edge runtime. It does not fit a team that wants a drop-in PDF library, since the engine deliberately stops before rendering and you own that side, and it does not fit a project unwilling to depend on a layout engine whose architecture is backed by a pending patent. Before you adopt it, read the quick start and build the workspace yourself, then compare a page of your own document against the debug output, because the coordinates are the product and you need to see them before you trust them.

## FAQ

### What is VMPrint and is it a PDF library?

The README is explicit that VMPrint is a layout engine rather than a PDF library or a renderer. It decides glyph positions and page breaks and returns a flat array of exact X and Y coordinates for every box and text run, and you then render that output to PDF, a Canvas, a word processor view layer or a WebGL pipeline yourself.

### How does VMPrint resolve a table of contents that needs page numbers?

Heading actors emit committed signals as their geometry settles, and the table of contents actor observes those signals inside the same simulation and assembles accurate entries, so the page numbers are exact and no second layout pass is needed. The README contrasts this with prior systems, which use a second pass, an approximation or auxiliary files.

### Does VMPrint need HarfBuzz, ICU or any native binary?

No. The README states that multi script and bidirectional layout is implemented in pure JavaScript with no HarfBuzz, no ICU and no system level binary, covering Arabic, Hebrew, Thai, Devanagari, CJK and Latin on one line, and that the engine runs in a V8 isolate with no native dependency.

### What is the difference between VMPrint and running headless Chrome through Puppeteer?

The README describes the headless Chrome route as needing a full browser process per worker, roughly 300 MB of RAM, hundreds of milliseconds of cold start overhead and subprocess privilege, while VMPrint runs inside an existing Node.js process or V8 isolate with no browser and no subprocess. The project gives its own timings, such as 326 pages warm in 718 ms, which are its own claims rather than independent measurements.

### How is the VMPrint repository organised and built?

It is a private npm workspace named vmprint-workspace with workspaces for contracts, engine, cli, pressrun, preview and globbed contexts, font manager and transmuter directories. The root build script chains the workspace builds in dependency order, and a sync script, node scripts/sync-shared-engine.mjs, keeps the shared engine mirrored between packages.

## Sources

- [cosmiciron/vmprint on GitHub](https://github.com/cosmiciron/vmprint)
- [License: Apache-2.0](https://github.com/cosmiciron/vmprint/blob/main/LICENSE)
- [Project website](https://cosmiciron.github.io/vmprint/)
- [README](https://github.com/cosmiciron/vmprint/blob/main/README.md)
- [Releases](https://github.com/cosmiciron/vmprint/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/cosmiciron-vmprint