LiveFigure: Editable Science Figures

• LiveFigure is an agentic framework that transforms methodological text into editable, vectorized scientific figures through a multi-stage, cognition-inspired workflow.
• It performs reference retrieval, blueprint planning, asset assembly, and iterative refinement using a curated skills library and self-correction loops to ensure precise layout control.
• Evaluations show that LiveFigure significantly reduces manual edits and improves publication readiness compared to traditional raster methods and code-based visualization tools.

LiveFigure is an agentic framework for generating editable scientific illustrations from methodological text using VLM agents. It is designed for the production of semantically precise, natively editable vector figures for scientific publishing, and it targets Microsoft PowerPoint as the native, fully editable vector canvas. The framework imitates a multi-stage workflow associated with human researchers—reference retrieval, blueprint planning, asset assembly, and iterative refinement—so that the final output is not a flat raster but a fully vectorized, editable figure intended to meet publication standards (Shao et al., 22 May 2026).

1. Problem setting and conceptual scope

Scientific figures in academic papers must be both semantically precise and natively editable in vector form. LiveFigure is explicitly motivated by the mismatch between that requirement and the behavior of existing generative image models, which produce only flat rasters that cannot be corrected or laid out at the object level. The framework therefore treats editability as a structural property of the output: valid editability involves structured transformations of graphical elements, scales, attributes, and text, rather than simple pixel-level changes (Shao et al., 22 May 2026).

This formulation distinguishes LiveFigure from two common alternatives. Raster-oriented prompt-based editing can modify appearance, but it does not directly support manual correction or layout adjustment in the form typically required for submission. Code-based tools such as Matplotlib and TikZ, as characterized in the source description, either yield simplistic, inflexible visuals or require expert coding. LiveFigure addresses this gap by synthesizing executable python-pptx scripts and producing publication-ready PPTX files with zero manual coding (Shao et al., 22 May 2026).

At the level of formal decomposition, the system takes input methodological text $\mathcal{T}_{in}$ and applies three modules—$\Psi_{\text{plan}}$, $\Psi_{\text{assemble}}$, and $\Psi_{\text{refine}}$—to obtain the final editable figure $\mathcal{F}_{final}$. This three-stage decomposition is presented as a “Cognition-Inspired Procedural Construction” paradigm, emphasizing interpretability and modularity rather than direct one-shot generation (Shao et al., 22 May 2026).

2. Blueprint planning via prior induction

The first stage, $\Psi_{\text{plan}}$, performs blueprint planning by grounding the input text in a curated knowledge base of prior scientific figures. The knowledge base is defined as $\mathbb{K}=\{(v_i,c_i,d_i)\}$, where each element contains a figure $v_i$, its caption $c_i$, and a dense technical description $d_i$. Retrieval is performed by selecting the top-$\Psi_{\text{plan}}$0 references under embedding similarity: $\Psi_{\text{plan}}$1 where $\Psi_{\text{plan}}$2 is a pretrained embedding model, with Qwen3-Embedding given as an example (Shao et al., 22 May 2026).

After retrieval, a VLM examines layouts in $\Psi_{\text{plan}}$3 and adapts them to $\Psi_{\text{plan}}$4, producing a structural plan $\Psi_{\text{plan}}$5. A subsequent image-generation step renders a coarse schematic “sketch,” denoted $\Psi_{\text{plan}}$6, which functions as the blueprint for downstream construction. The source description characterizes this step as drawing inspiration from high-quality references in previous works rather than directly copying them, and this suggests that the planning module serves as a layout prior rather than a pure retrieval system (Shao et al., 22 May 2026).

The planning stage also includes asset generation for complex entities that are difficult to realize with simple geometric primitives. For such entities, the framework batch-generates an $\Psi_{\text{plan}}$7 grid, then auto-crops and removes backgrounds to form an asset library $\Psi_{\text{plan}}$8. This separation between a coarse blueprint and an auxiliary asset set is structurally important: it allows later code synthesis to combine standardized drawing skills with externally generated components when the visual vocabulary of PowerPoint primitives alone is insufficient (Shao et al., 22 May 2026).

3. Script generation via standardized skills

The second stage, $\Psi_{\text{plan}}$9, converts the blueprint $\Psi_{\text{assemble}}$0 and asset library $\Psi_{\text{assemble}}$1 into an executable python-pptx script $\Psi_{\text{assemble}}$2, which yields the initial figure $\Psi_{\text{assemble}}$3. The central device in this module is a standardized skill library $\Psi_{\text{assemble}}$4, implemented as a curated Python module skills.py exposing atomic, pre-debugged functions such as add_container, add_block, and add_connector. These functions encapsulate complex layout logic and constrain the synthesis space to operations that are known to be compatible with the target rendering environment (Shao et al., 22 May 2026).

The module also injects “experience” in the form of negative constraints, denoted $\Psi_{\text{assemble}}$5. These are forbidden patterns that the model is instructed to avoid; one example given is “never call slide.shapes.add_shape(MSO_SHAPE.LINE,…)”. In practical terms, the assembly prompt includes the blueprint description, the skill specification, the negative constraints, and a strict requirement to output only raw Python code. A representative prompt skeleton is:

$\mathcal{F}_{final}$2

The generated code is executed in a sandbox. If execution fails, the framework enters a self-correction loop in which the VLM receives the current code, the error trace $\Psi_{\text{assemble}}$6, the skill specification, and the negative constraints, then emits a revised program. The process repeats until the script runs successfully or a maximum iteration count is reached. The mechanism is summarized in the provided pseudo-code:

$\mathcal{F}_{final}$3

This stage is the point at which LiveFigure departs most clearly from raster generation. The produced artifact is not merely an image but an executable construction program whose output remains editable at the object level inside PowerPoint (Shao et al., 22 May 2026).

4. Visual diagnostics and iterative refinement

The third stage, $\Psi_{\text{assemble}}$7, addresses the residual gap between a syntactically valid PPTX and a visually publishable scientific illustration. Its objective is to identify subtle visual defects in $\Psi_{\text{assemble}}$8 and apply targeted code updates until the output is judged satisfactory. The paper describes this as an Observe–Diagnose–Refine loop with four steps: render the current code to a snapshot image $\Psi_{\text{assemble}}$9; invoke a VLM critic to produce an actionable issue list $\Psi_{\text{refine}}$0; merge the issue list into the code to obtain $\Psi_{\text{refine}}$1; and repeat until $\Psi_{\text{refine}}$2 or convergence is reached (Shao et al., 22 May 2026).

The issue list is explicitly operational rather than stylistically vague. An example from the source text is: “[CONNECTORS] Arrow crosses text → reroute to elbow”. This indicates that the critic is expected to detect local compositional errors—connector routing, overlaps, legibility defects, and related layout pathologies—that are difficult to eliminate during the initial assembly pass. A plausible implication is that refinement functions as a visual verification layer over code generation rather than as a second, independent generator (Shao et al., 22 May 2026).

Because each refinement action is expressed as a code update, the system preserves editability throughout the loop. The final output $\Psi_{\text{refine}}$3 is thus not a post-processed bitmap but the execution result of a refined program. Figure 1 of the source paper, as described in text, presents this architecture as three horizontally aligned panels labeled (I) Planning, (II) Assembly, and (III) Refinement, with agent icons, sample blueprints, code snippets, and before/after snapshots, emphasizing the staged nature of the pipeline (Shao et al., 22 May 2026).

5. Evaluation methodology and reported results

LiveFigure is evaluated both by editability-oriented measures and by judgments of visual design and content fidelity. The core editability metric is “Edit Distance” $\Psi_{\text{refine}}$4, defined as the number of atomic PPTX-XML operations—modify, add, delete—a human must perform to turn $\Psi_{\text{refine}}$5 into a publication-ready figure $\Psi_{\text{refine}}$6: $\Psi_{\text{refine}}$7 From this, the readiness or adoption function is defined as

$\Psi_{\text{refine}}$8

This metric directly operationalizes the claim that editable figures should be judged by how much object-level correction they still require, not solely by perceptual resemblance (Shao et al., 22 May 2026).

The quantitative results reported in the source are concentrated and unusually specific. LiveFigure reaches $\Psi_{\text{refine}}$9, meaning that 80% of figures require at most 17 edits to become publication-ready. Its median edit distance, corresponding to 50% adoption, is 8 steps, which is reported as $\mathcal{F}_{final}$0 lower than the w/o-skills ablation at 31 steps. The strongest raster baseline, NanoBanana, reaches only 24% at zero edits. Under full input consisting of caption plus method, LiveFigure averages 7.89/10 on a VLM-judge suite of nine metrics spanning Visual Design, Information Clarity, and Content Fidelity; in the same summary, Graphviz scores 5.78, and LiveFigure’s Accuracy score is 8.29 versus GPT-Image1.5’s 7.06 (Shao et al., 22 May 2026).

Evaluation aspect	Reported result	Comparator
Publication-readiness	80% at 17 manual edits	$\mathcal{F}_{final}$1
Median edit distance	8 steps	31 steps for w/o-skills ablation
Zero-edit readiness	24% for strongest raster baseline	NanoBanana
VLM-judge average under full input	7.89/10	Graphviz: 5.78
Accuracy metric	8.29	GPT-Image1.5: 7.06

The human study results are reported in two forms in the provided material. The abstract states that LiveFigure secures a 60% win rate against NanoBanana, while the detailed evaluation summary states that, in double-blind A/B tests, LiveFigure wins approximately 69% of the time against NanoBanana and 60% against GPT-Image1.5. The same summary further reports win rates above 97% against code tools such as Matplotlib and TikZ, and states that all 95% confidence intervals exclude 50%, confirming statistical significance. Figure 2 is described as showing cumulative adoption curves with vertical lines at 50% adoption (8 edits) and 80% adoption (17 edits), visually tying the readiness metric to the edit-distance threshold (Shao et al., 22 May 2026).

6. Limitations, adjacent systems, and research context

The source description identifies two principal limitations. First, the agents sometimes render every intermediate step explicitly, producing overcrowded schematics. This is characterized as a tendency to over-complicate. The proposed future direction is RLHF or preference fine-tuning to teach strategic abstraction of only core contributions. Second, current prompts yield a single “generic” aesthetic, whereas researchers and venues demand diverse styles such as Nature versus NeurIPS conventions. The proposed remedy is to curate a venue-annotated figure corpus and train style adapters for fine-grained, customizable appearance (Shao et al., 22 May 2026).

Within the broader landscape of figure-related systems, LiveFigure should be distinguished from both LIVE and Hanstreamer. LIVE, “LaTex Interactive Visual Editing,” focuses on clickable, print-safe interactivity in ordinary LaTeX-to-PDF workflows by generating an image plus a small .tex overlay file and placing \cite{…} hyperlinks over figures with overpic; its interactivity lives entirely in PDF-internal hyperlinks built by hyperref (Lin, 2024). Hanstreamer, by contrast, is a webcam-based live data presentation system that performs real-time gesture recognition on webcam video, maps gestures to visualization state changes, and renders layered video, charts, maps, network graphs, and DimpVis-style time-series explorations in the browser for use with Zoom or Microsoft Teams (Kristanto et al., 2023).

These comparisons clarify the scope of LiveFigure. LIVE augments static paper artifacts with PDF-native interactivity, and Hanstreamer supports real-time, webcam-mediated data presentation. LiveFigure addresses a different problem: the generation of publication-ready scientific illustrations that are inherently editable in vector form. This suggests a broader taxonomy in which “live” figure systems differ not by nomenclature but by substrate—PDF overlays, browser-based presentation canvases, or editable PPTX documents—and by whether the central challenge is interaction, presentation, or construction (Shao et al., 22 May 2026).