Why AI Never Touches a Pixel Coordinate: Layouts

Quick answer: Here's the fastest way to generate a broken slide: ask an LLM to produce design JSON with coordinates.

Give a model a canvas and a schema that says "title: {x, y, width, height}, subtitle: {x, y, width, height}" and it will cheerfully return numbers that look reasonable. Sometimes they even are. But text is not a fixed-size object — it reflows. The moment the headline is a character longer than the example, or the font metrics differ slightly, or a translated word grows by 30%, the box overflows. The model has no way to measure what it's producing; it predicts coordinates from statistical patterns, and statistics don't know your headline. Overlapping text, random margins, widows orphaned at the edge of a slide — this is the visible signature of an LLM doing geometry.

The fix isn't a better prompt or a smarter model. The fix is to never let the model do geometry in the first place.

The core separation: content contract vs. visual layout

Neatico's generation pipeline is split into two halves with a hard contract between them.

The LLM produces a content plan — pure semantic JSON. It decides what the work says: a title, a set of pages, and on each page a sequence of typed content blocks. The block types are editorial, not visual: paragraph, steps, features, comparison, code, parameters, quote, chart, image. Every claim can carry an evidence reference back to the source material the user pasted. There are no coordinates, no fonts, no colors, no margins in this JSON. The model is kept inside the part of the problem it's actually good at — reading, organizing, and writing.

The deterministic engine produces the design — authored TypeScript that turns a content plan into a finished canvas. It runs entirely in the browser, on the real canvas, and it's the only component that ever emits pixel positions.

The contract between them is what makes the system reliable. It's a shared TypeScript package (we publish it as @neatico/visual-core and use it identically in the frontend and backend), and it defines a finite set of authored layouts: ninety-two slide layouts and ninety-seven social layout scenes. Each layout declares a contract — what content it requires (title mandatory, for example), how many items it accepts (a comparison needs two, a checklist up to fifteen), and what canvas aspect ratios it supports.

How a page actually gets composed

When a page is composed, the engine doesn't ask the model "which layout looks good." The flow is:

Filter by contract. The engine takes the page's content blocks — how many items, what kinds, whether there's a value or a quote — and keeps only layouts whose contracts are satisfied at the target aspect ratio.
Match by scene. The content plan carries a semantic scene (editorial, event, metrics, launch, spotlight, quote, and so on). Layouts authored for the same scene are ranked first.
Rank candidates. A deterministic fallback order — general-purpose structures like cards, two-column, checklist, steps — guarantees there is always a valid candidate. The selection logic returns an ordered list, never a dead end.
Render and measure. The chosen layout is rendered to the canvas, and the actual rendered text is measured using the browser's text measurement primitives.
Overflow gate. If anything doesn't fit, the engine responds: reduce the type scale, tighten spacing, move a block to its own page, or pick the next eligible layout — then re-render and measure again.

That last step is the whole game. Layout is a constraint-satisfaction problem, and constraints are useless without measurement. The engine can split a page's content across pages mid-block at a natural break, move a body paragraph onto its own slide, or shrink a photo-led poster's density — but every decision is recomputed against the real canvas, not estimated.

Why this architecture is more than an implementation detail

The output is reproducible. The same content plan produces the same design every time. When a user reports a bug, we can reproduce the exact canvas, inspect the contract that selected the layout, and fix the engine once. When a model emits coordinates, every failure is a fresh improvisation that can't be debugged.

The output is editable. Because every element is a real layer — text, shape, image, group — with semantic structure, the editor can change anything. The AI can also make natural-language edits safely: a "make this darker" request returns a small, whitelisted patch of allowed properties, validated against ranges, enums, and the font catalog. Locked layers are protected, IDs and parents are preserved, and a request the patch format can't express returns "unsupported" rather than silently breaking the page. A model that generates whole-page coordinates can't do partial edits — it only knows how to re-improvise the entire canvas.

The output survives translation. Text grows. German and English headlines take 10–30% more space than the English version; CJK headlines are denser but need larger type; right-to-left content changes the whole reading direction. When coordinates are fixed in the source design, translation shatters them. When the layout is computed from a content contract, the same engine re-composes the translated page in each of the fifty languages we support and re-runs the overflow gate, with CJK fonts mapped per locale (Yu Gothic for Japanese, Malgun Gothic for Korean, Microsoft YaHei for simplified Chinese, SimSun for traditional).

The output is scalable. A new visual design is a new authored layout plus a contract, not a new prompt or a new model behavior. The layout library grows without changing the AI contract.

The pipeline around the engine

The engine is only the middle of a stricter system. Before the engine ever sees a page, the content plan goes through a validation pipeline — evidence checks, coverage checks, and bounded repair attempts — which we've covered in detail here. After the engine, the export layer serializes the same deterministic layer tree to real files: PNG and PDF from the browser, and a native, editable PowerPoint, which is a different and harder problem than it looks.

Every one of these stages shares the same principle: the probabilistic component is contained, and the deterministic component owns correctness. The model is a writer; the engine is a designer; the user is the editor.

The tell, and the test

If you're evaluating any AI design tool, open its output and change a word. Make a headline two words longer. Translate one slide. Then watch the edges.

If boxes overlap, margins shift, or text gets cut off, the model is doing geometry. There is no amount of "AI" that fixes that — only an architecture that separates content from layout, measures real text, and treats the canvas as a constraint system rather than a suggestion box.

The AI's job is to understand what you're trying to say. The pixel coordinates belong to us. Try it on one of your own texts and see where it breaks.