If you want to understand VMPrint, you have to unlearn how layout engines work.
Every document renderer you know—whether browser-based, LaTeX, or PDF generator—is a pipeline. You feed it a document tree. It walks down the tree. It crunches measurements. It spits out pages. It is a one-way trip.
This pipeline approach is why complex layouts routinely fail. If a table of contents needs accurate page numbers, the pipeline must run twice. If an element expands, the whole DOM tree has to recalculate, causing a cascading O(N²) failure. It is slow, brittle, and full of blind spots.
VMPrint throws the pipeline away.
It is not a layout engine in the traditional sense. It is a microkernel operating system built for spatial simulation. It treats layout not as a math problem to be solved once, but as a living world that settles over time.
Here is what that actually means.
Traditional engines rely heavily on nested trees—a Document Object Model (DOM) or a Scene Graph. The renderer recurses into children, calculates boundaries, and resolves clipping at paint time. Layout decisions remain entangled with rendering.
VMPrint eliminates the need for a DOM entirely.
Because VMPrint relies on physical displacement and autonomous actors (more on this below), it resolves spatial geometry natively during simulation. By the time the engine hands off the output, every positioning decision has been encoded as an absolute coordinate. The renderer receives a completely flat array of primitives in z-order. It makes zero layout decisions. It just paints.
This flatness makes layout changes fully observable, diffable as JSON, and wildly fast. It structurally excludes entire categories of layout bugs.
In traditional systems, the page is everything. Content is poured into pages. A page break is a traumatic rupture in existence.
VMPrint flips this upside down. The primary canvas is a persistent physical substrate called the World Plain. It has a stable origin and a continuous width. As the engine runs, an "exploration frontier" pushes forward into unvisited space. It works like the fog of war in a strategy game.
Pages are Local Maps: Pages do not dictate the layout. They are treated as part of the world, functioning more like local maps or viewport projections in a game. They form the continuous physical terrain.
Zones as Sub-Regions: Zones act as defined sub-regions within this world. Because the world is continuous, a zone can naturally cross page boundaries without any complex "linked-frame" hacks. It behaves much like the interior of a tavern that seamlessly spans across two different towns on a map.
The River: What we typically think of as "ordinary sequential document flow" is not the world itself. It is simply a current, a river flowing through the broader World Plain Host. You can drop explicit structures (like an invisible hazard field) into the plain, and the river of text will naturally flow around it.
In a pipeline, elements are dead text boxes. In VMPrint, elements are autonomous physical actors called Packagers.
Packagers live on the board. They negotiate space with their neighbors. But their most powerful trait is that they are designed to self-disassemble and re-assemble, much like Lego characters.
When a table hits a page boundary, it doesn't just awkwardly overflow or force a global recalculation. The Table packager splits itself. It breaks apart, negotiates the highly constrained terrain of the page break, and reconstitutes its identity on the other side—carrying over header rows and resuming its geometry perfectly.
This is how VMPrint solves complex layout issues around obstacles and page boundaries. It doesn't rely on massive conditional logic in the core engine. It gives actors the ability to break apart and come back together. That is their purpose.
Prior systems can wrap text around a simple rectangle or circle. But what if a document contains an irregular creature, like a dragon, crawling through the text?
VMPrint handles this via Exclusion Assemblies. An actor can publish a composed exclusion field made of multiple simple, cheap primitives (circles, rects). To the engine, these primitives act together as one large articulated shape.
This provides massive desktop-publishing capabilities natively. A complex float, an irregular pull-quote, or an animated world actor can move through the page, visibly parting the text like matter without needing a heavy, general-purpose rigid-body physics engine.
In old engines, if one element changes, the whole document often recalculates. It is a massive waste of energy.
VMPrint solves this with a kernel-level actor lifecycle. Most actors stay dormant and cost nothing. They subscribe to "topics," and when a relevant event happens, they are selectively awakened.
When an actor wakes up and updates, it reports its new state to the kernel through a three-tier classification:
- None: The actor didn't change. Cost is zero.
- Content-Only: The actor changed what it says, but not its size (e.g., a page counter ticking from 11 to 12). The engine redraws it in place. No spatial recalculation occurs.
- Geometry: The actor grew or shrank. The engine records exactly where this happened. It uses precise anchored checkpoints to rewind and replay only the specific downstream actors affected by the shift. Upstream actors are actively excluded from replay.
This is how VMPrint runs fast. It responds to change at the exact minimum necessary cost.
Traditional document scripting relies on DOM events (clicks, hovers) or broad mutation observers that trigger massive recalculations.
VMPrint uses a kernel-backed messaging bus. Because the engine treats the layout as a simulation, actors communicate by publishing signals and subscribing to topics. If a chapter heading changes its physical page location, it publishes a "world fact" to the bus. A Table of Contents actor, lying dormant and listening on that specific topic, wakes up, observes the committed fact, and updates its own geometry.
This branch-aware, transactional communication allows deeply disconnected elements to synchronize natively. They react exactly when the spatial situation changes, completely eliminating the need for the messy "two-pass" post-processing orchestration that plagues older engines.
When you script traditional layout engines, you perform "bone surgery"—you mutate the underlying DOM, forcing the engine to tear down and rebuild the document from scratch.
VMPrint's scripting runtime protects the instruction manual. It never scribbles over the authored blueprint. Instead, it operates on the live participant composition—the active Lego characters standing on the board.
If a script executes replaceElement(Batman, Superman), the engine doesn't rewrite the source structure and restart the movie from page one. It simply despawns the live Batman participant from the active queue, instantiates Superman, splices him into the same queue position, and lets the normal settlement physics naturally propagate any downstream consequences from that precise spatial frontier. Local scripted changes behave like local physics updates, not global document refreshes.
Sometimes the engine has to make a guess. Will this paragraph look better on the next page? How do we handle "keep-with-next" policies without messing up the world?
VMPrint handles this with Speculative Transactions. Instead of capturing ambient snapshots "just in case", the engine uses strict, transaction-scoped boundaries.
When predicting a layout outcome, the kernel takes a perfect deterministic state snapshot. It executes a speculative layout branch inside an isolated buffer. If the result satisfies continuity rules, the branch commits. If it fails, the engine executes a deterministic rollback, restoring the exact bit-for-bit snapshot, and tries an alternate path.
These rollbacks are safe, fast, exact, and explicitly logged for telemetry.
A reactive layout system can easily get stuck in an infinite loop. Actor A moves, pushing Actor B. Actor B moves, pushing Actor A.
Prior art has no mechanism for this. They just freeze.
VMPrint treats oscillation as a core problem, not an afterthought. The runtime enforces bounded settlement caps. If it spots a repeated-state signature across settlement cycles, it executes a deterministic hard stop. It gives you a clear diagnostic report showing exactly which actor caused the loop, what signal triggered it, and the frontier position where the cap was reached.
Because VMPrint is a simulation, it has a discrete, kernel-owned simulation clock. This clock ticks independently of pages or rendering.
This leads to a breakthrough: Print-as-world-slice.
A traditional engine stops when it runs out of content. VMPrint stops when a configurable "stopping policy" is satisfied. You can capture the document when everything settles into spatial equilibrium (standard print behavior). Or, you can tell the engine to capture the world after exactly ten ticks. Each page of the output will show the world state at a successive tick.
You aren't just printing a static document. You are capturing frames of a running simulation history.
To make all of this work without turning into spaghetti code, the architecture enforces strict separation across four layers.
- The Simulation Kernel (The Substrate): The bedrock. It manages mutable world state, actor identity, explicit transactions, rollbacks, and the simulation clock. Crucially, the kernel knows nothing about typography or document semantics.
- Engine Systems (The Runtime): Manages physical collisions, communication between actors, viewport planning, and oscillation detection.
- Document Semantics: The translation layer. It maps authored AST elements (text, headings, tables) into the physical actors (Packagers) on the board.
- Print / Composition Handoff: The output layer. It converts the settled world coordinates into viewport-projected, flattened arrays for rendering contexts (PDF, Canvas, SVG).
The boundary around the kernel is absolute. No document-specific logic is allowed inside.
When you build with VMPrint, you are not writing formatting rules for a dumb pipeline. You are placing intelligent, composable actors into a physical simulation.
It handles cyclic dependencies in a single pass. It isolates changes to prevent cascading slowdowns. It replaces the fragile DOM with flat, deterministic physical output. It gives you true programmatic control over how a document settles across both space and time.
It brings the rigor of an operating system and the performance of a game engine to the world of document layout. Welcome to the spatial simulation era.