How Vizcept Draws Figures — and When to Double-Check

Vizcept has two drawing pipelines. Which one your figure goes through decides what you need to check.

All three code-drawn types go to the image model instead when you upload a sketch or photo, when your text has characters the font can't set (Chinese, Japanese and Korean among them), or when the analysis fails. Those figures need the same proofread as any image-model figure. Each tool page says which pipeline it uses.

1. Analysis. A language model reads your sentence and returns only its structure: a labeled bracket string for a syntax tree, or a Reed–Kellogg structure for a sentence diagram. It does not draw anything.
2. Checks. Code verifies the structure before drawing: brackets must balance, every node needs a label, and every character must exist in the font. If a check fails, the analysis is retried or sent to a second model.
3. Layout. Code positions every node and line, then typesets the text in Tinos, a Times-compatible font. The PNG is rendered from vector outlines; the SVG download keeps real text you can edit.
4. Fallback. Sketches and photos, sentences with characters the font can't set (such as Chinese, Japanese or Korean), and analyses that fail all go to the image model, so you still get a figure, just more slowly, and it needs the full proofread below. If your input contains no sentence at all, the request fails and no credits are charged.

When code draws the figure, it cannot misspell a word or smudge a label. It can only draw what the analysis says — which is why the analysis is the part to read.

The layout code has to pass a test suite before any change ships.

• Sentence diagrams: for a set of hand-written sentence patterns and 16 analyses of real sentences, every word in the analysis must appear in the drawing, and no two pieces of text may overlap. Overlap is measured on the actual glyph outlines, not estimated.
• Syntax trees: bracket strings must parse with the words kept in their original order under their category nodes; unbalanced or empty brackets are rejected; every trace produces a movement arrow, and no trace means no arrow.
• Fonts: characters the font cannot draw, such as Chinese, Japanese and Korean, are detected before drawing, so those requests go to the image model instead of printing empty boxes.

What the tests do not check is whether the analysis is linguistically right for your framework. That part is a model's judgement, so read it the way you would read a classmate's answer.

• Right-to-left languages. Hebrew and Arabic sentences are not laid out right-to-left yet, so word order can come out reversed. Don't use them for published trees.
• Chinese, Japanese and Korean. These go to the image model, because the typesetting font does not cover them. Proofread the characters.
• LaTeX export. There is no qtree or forest export yet. Download the SVG or PNG instead.
• Contested analyses. Where frameworks disagree — ellipsis sites, scrambling, small clauses — the model picks one analysis. Tell it which one your course uses.

An image model paints text as pixels. It makes mistakes a person would not, and the same ones keep coming up:

• Misspelled or invented words, especially in long technical terms.
• The same label placed twice, or one box drawn twice and wired twice.
• Arrows pointing the wrong way or joining the wrong boxes.
• Numbers that drift: 1,234 becomes 1,243, and totals stop adding up.
• Text you never asked for, such as an invented subtitle.

A five-minute proofread catches almost all of it:

1. Read every label against your source — Chapter 2 for a framework, the screening spreadsheet for PRISMA, the methods section for a workflow.
2. Trace each arrow from start to end and say the relationship out loud.
3. Re-add every number. PRISMA counts must reconcile from one box to the next.
4. If something is wrong, mark it in the editor and describe the fix, or change the description and regenerate. Every version is kept in the Studio, so you can go back.

How often does it go wrong? On one framework description we ran ten times, the wording was right every time and the moderator arrow landed on the wrong path four times; the counts are in the FigureLabs comparison.

Conceptual frameworks moved to the analysis-plus-code pipeline, so construct names and hypothesis labels are now typeset rather than painted. PRISMA flow diagrams are next, because a wrong count there costs the most. Until a figure type moves over, its tool page says it is drawn by an image model, and this page is updated when that changes. We don't give dates we can't keep.