Paper Architecture Web Drawing

1. Banned visual modes

• SmartArt / PowerPoint flowcharts: equal-width rounded cards chained linearly, all nodes with the same corner radius and border.
• Dashboard / poster style: right-side KPI column, result-card stack, marketing badges, statistic stickers, glow emphasis.
• Web-UI collage: title bar + subtitle bar + content card patterns; pill-badge arrays.
• Big box + arrow + bottom legend as the dominant frame.
• Top stage-label + bottom caption / problem statement / method summary. The figure should be self-explanatory.
• bypass / feedback / dashed line crossing through module titles, equations, badges, or result numbers.
• Small font + large whitespace in exchange for content capacity.
• High-saturation red / green / purple, or five or more salient light-color blocks at once.

2. Workflow

2.1 Read the paper

• Look for .tex / .md / .txt in the workspace; read Abstract / Method / Approach / Overview / Framework.
• If multiple candidate files exist, confirm with the user first — do not guess.
• Only read context needed to reconstruct the main pipeline.

2.2 Structure extraction (mandatory before drawing)

For every key module fill out these 5 fields. If you cannot articulate one, do not draw the module:

2.3 Pick a layout family (in order of priority)

1. Explicit feedback / iteration / alternating optimization / until convergence → Loop / U-shape
2. train/infer or stage1/stage2 or coarse/fine or retrieve/generate → Two-stage
3. ≥2 semantically independent branches merging into a shared main module → Multi-branch with merge
4. Narrow column / single-column vertical reading → Linear vertical
5. 3-6 serial stages, no strong feedback → Linear horizontal (default)
6. Local complex substructure embedded in the main chain → Hybrid composition

Tie-breakers: prefer the layout that preserves a strong visual center, gives the key mechanism panel enough area, minimizes arrow crossings and diagonal text overlaps, and forms a natural input-vs-output contrast.

Veto conditions (any of these → switch layout):

• No room for a main illustration; all modules forced into equal-weight small boxes.
• Need >2 long cross-region connectors to convey the main flow.
• Key equations forced into corners.
• Output region and auxiliary text fighting for space.
• Must shrink font or add whitespace to fit.

2.4 Default blueprint

Input object → 2-3 mechanism panels → output object

• Left: tensor / weights / KV cache / tokens / feature grid as a visualized input object (NOT a text box).
• Middle: each panel centers on a main illustration, not uniformly-sized small cards. Auxiliary objects (codebook / sensitivity map / objective / memory) anchor to their mechanism.
• Right: the transformed object of the same kind, preferring structural change over KPI summary.
• Input ↔ output reuse the same graphic motif to show state change (e.g. same-shape cache blocks before/after compression).
• Highlight only 1–2 core contribution modules: same-family slightly heavier border / slightly darker fill / local bracket / callout. Never via high saturation or large badges.

2.5 Palette (pick 1 of 5; one family across the whole figure)

Color roles (consistent across any chosen family): Primary background (normal modules), Secondary background (minor modules), Accent background (contribution modules), Input/Output background (lighter), Primary border, Accent border, Arrow color: one dark color across the whole figure, Main text, Secondary text. Never mix families.

2.6 Typography

• 2–3 stroke widths: main flow / secondary structure / coordinate auxiliaries.
• Small / medium corner radius; avoid web-card-style large rounding.
• Sans for labels + serif for equations.
• Short stable module titles, no slogans; subtitles default to omitted.
• Training-only branches: lighter fill + dashed arrows.
• Long paths (bypass, feedback, training-only branches) follow the outer edge of regions; do not cross dense text inside sub-panels.
• Compactness first: align, share edges, tighten via grouping. NEVER reduce font size to fit content.
• Asymmetric layouts allowed; area reflects importance; never chase column parity.

2.7 Abstract object → glyph (Python vs hand-written SVG)

Rule: if the glyph carries numerical / distribution / geometric content → Python-generated SVG. If the glyph is a structured layout (box, arrow, equation slot) → hand-written SVG.

2.7.1 Python-generated SVG sub-figures (matplotlib)

Place a figures/<paper>_components.py script; each subplot saves to a separate .svg; the main HTML embeds them inline or via <img src=...svg>. Prefer inline (single-file delivery, second-pass editable).

Minimum skeleton:

import matplotlib
matplotlib.use("Agg")
import matplotlib.pyplot as plt
import numpy as np

plt.rcParams.update({
    "font.family": "DejaVu Sans",
    "font.size": 14,
    "axes.linewidth": 1.0,
    "axes.spines.top": False,
    "axes.spines.right": False,
    "svg.fonttype": "none",   # keep text as <text>, do not outline
})

def save(fig, path):
    fig.savefig(path, format="svg", bbox_inches="tight",
                pad_inches=0.05, transparent=True)
    plt.close(fig)

Hard rules:

• svg.fonttype="none": text stays as editable <text>, not paths.
• transparent=True + main HTML white background, avoiding double background layers.
• Per-subplot font size ≥ 12 (after embedding scale, still readable).
• Use only your palette family (see §2.5); never matplotlib's default tab:blue.
• One figure per function; never plt.show() in the script.

2.7.2 Inline embedding

After Python produces comp_a.svg, in the main HTML:

<g transform="translate(120, 80)">
  <!-- inline-svg-include: comp_a.svg -->
</g>

Two delivery paths:

• Copy inline: paste comp_a.svg's inner <g>...</g> into the main SVG at the corresponding spot; drop the outer <svg> header.
• Object reference: in main HTML, <image href="comp_a.svg" x=.. y=.. width=..> or <foreignObject>. MUST verify rendering in the browser before delivery.

After inline embedding, manually adjust size / position: matplotlib's default viewBox differs from the main figure's coordinate system; wrap in a <g transform="translate(x,y) scale(s)">.

2.8 Equation placement

• Every key equation has a dedicated slot (local white-background equation slot / module-internal equation strip / anchor aligned to glyph). Never a floating web-sticker.
• Long equations split into two short labels or shorter equivalent forms; never let a single long line crush a panel.
• objective / update / normalization / threshold equations live inside their module's slot, not piled in a unified bottom strip.
• The equation chip sits ≤ 15 px below its main illustration; no big air gap between them.

2.9 Compactness numerics (hard targets)

Most "doesn't look like a method figure" failures come from loose layout. Enforce these upper bounds:

Panel-equal-height trap: 4 panels in one row need not be equal height. Input/Output typically 200–300 px shorter than mechanism panels. Forcing equal height = manufacturing whitespace.

How to measure: after rendering, use browser dev tools. Or temporarily draw <rect> boundary markers inside the SVG to eyeball dead-space ratios.

2.10 Mandatory ≥ 10-round self-check loop

After writing the HTML, never deliver directly. Run 10 iterations from the table below; each round:

1. Render PNG with chrome --headless --screenshot.
2. Open the PNG; write down "this round's focus dimension and 3 most non-compliant spots" (concrete only; "looks fine" is banned).
3. Fix HTML / Python / regenerate the sub-figure.
4. Re-render.

Never skip a round. If a round finds nothing because earlier rounds already fixed it, explicitly record "this round 0 issues" — do not silently skip.

Round 11+ optional: only when a previous fix triggered a new violation (e.g. tightening clipped some text); add rounds until stable.

2.11 Quick-rollback conditions

During iteration, if any of the following holds, roll back to §2.4 default blueprint and redraw; do not keep tuning:

• 3 rounds of compactness work still cannot hit the §2.9 numbers.
• The main illustration is essentially stacked text, not graphics.
• viewBox shrinking always leaves large whitespace → usually caused by forced panel-equal-height (§2.9 trap).

3. File locations

• If the repo has figures/ or dist/figures/ → output there.
• Otherwise put the files next to the paper source.
• Default artifacts:
  • method_architecture.html (main figure, inline SVG)
  • method_architecture.svg (homologous standalone SVG, optional)
  • <paper>_components.py (script generating Python sub-figures)
  • comp_*.svg (Python sub-figure source files, for later editing)
• The main HTML does NOT go online (MathJax / KaTeX CDN is the only exception).

4. Completion checklist

Confirm every item. Any miss → continue iterating:

• Single HTML file opens directly; pure white background; inline SVG dominates
• ≥ 3 real glyphs (heatmap / histogram / boxplot / scatter / matrix), with ≥ 1 Python-generated if numerical
• Each main mechanism panel has a main illustration, NOT just title + equation + cards
• Python sub-figures use svg.fonttype="none"; text is editable
• Python sub-figures use the same palette family as the main figure; no matplotlib defaults
• Compactness (§2.9): panel whitespace ≤ 15%, main illustration ≥ 65% of panel, cross-panel gap 20–40 px
• Panels NOT forced equal-height: Input/Output 200–300 px shorter than mechanism panels
• viewBox aspect ratio 0.45–0.65 (single-row 4-panel); top/bottom padding ≤ 30 px
• Equations sit in dedicated slots, aligned with their module; not floating; not crushed by codebook / arrow / badge
• LaTeX equations render correctly (MathJax / KaTeX); no ASCII pseudo-equations
• Font sizes meet the floor: 26 / 22 / 18 / 16 / 14
• All English labels; single-component description ≤ 10 words
• 1–2 core contribution modules highlighted (restrained: no high saturation, no big badges)
• Palette: single family, 3–5 shades; no gradients / shadows / glow / glass
• Main-flow arrows do not cross text / equations / badges; long paths follow outer edges
• Input ↔ Output reuse a graphic motif or form a sensible before/after contrast
• No top stage-label / phase-label; no bottom caption / problem statement / footer text
• No right-side KPI column / result-card stack / dashboard / poster summary strip
• Does not resemble SmartArt / PowerPoint / web component / product banner
• ≥ 10 rounds of self-check completed (§2.10), with a PNG screenshot and 3 spot notes per round
• Every arrow maps to a real data-flow / control-flow / supervision signal
• No invented modules / losses / feedback loops absent from the paper

5. Delivery contract

1. Single HTML file as the main figure (inline-SVG-dominant).
2. <paper>_components.py: script generating all Python numerical / geometric sub-figures.
3. comp_*.svg: Python sub-figure source files (so the user can edit later).
4. Optional: standalone method_architecture.svg.
5. Brief notes: main flow, auxiliary branches, Python sub-figure manifest, source files referenced.
6. When ambiguity remains, explicitly flag the undefined modules; do not invent.