light-figure-planning

Paper Figure and Table Design Planning

Positioning

Figures and tables serve the argument, not decoration. Each figure or table should first answer:Which claim does it support? If it were deleted, would the paper be missing a piece?

Planning Process

Read through the paper (or outline) + m06 results, and list all claims.
Match each claim with the most persuasive presentation form.Can run scripts/recommend_chart.py --task <比较/分布/关系/构成/趋势/排序/占比/不确定性> --fields <定类/定序/定量/时间...> --n-series N to get heuristic candidate chart-type ranking (based on Cleveland-McGill perceptual accuracy + task-family priors, outputting reasons/cautions) — it isinterpretable suggestions, not ground truth, and the final decision should be made manually by combining claim importance/domain conventions/journal preferences.
Mark priorities:Must-do(supports core contribution) / Can-do(enhancement) / Can-delete(redundant or weak).
Layout placement: which goes in the main text, which goes in the appendix, and how to group multi-panel figures.
Display item budget check: count the total number of F#+T# in the main text, and compare it with the target venue's upper limit (top journals/top conferences often 6–8 items, subject to the target journal's author guidelines).If over budget, force trade-offs, with a fixed cutting order: first cut "can-delete" → demote "can-do" to the appendix → leave "must-do" untouched (those whose deletion would remove the core argument must not be cut). Merging homogeneous figures and moving secondary analyses to the appendix are also ways to reduce item count. Write the total count check into the deliverable (see the quantity item in the self-check list). For a complete example, see examples/worked_example.md for the full claim→figure/table list panorama.

Figure and Table Type List (choose as needed, with suggested tools)

Concept/Method: framework diagrams, technical roadmap diagrams, model architecture diagrams, algorithm flowcharts, data flow diagrams. → For finely typeset editable sources, use diagrams.net/Draw.io (XML, with official MCP, diagram-as-code); for LaTeX-native use TikZ; for automatic layout of relationships/dependencies use Graphviz (dot); for sketches embedded in documents use Mermaid; for 3D structures/molecules/scientific visualization use Blender (+Molecular Nodes/SciBlend plugins).
Data: dataset schematic diagrams, sample distributions, annotation examples. → For statistical distributions use seaborn/matplotlib; for schematic layout use draw.io/TikZ.
Quantitative Results: main result comparison figures/tables, ablation figures, parameter sensitivity curves, convergence curves, ROC/PR, confusion matrices, radar charts. → matplotlib (fine typesetting) + seaborn (statistical convenience); for R use ggplot2; for interactive supplementary materials use Plotly/Altair.
Qualitative Results: real effect figures, model output examples, case studies, failure cases, interpretability visualizations (attention/SHAP/feature maps).
Tables: metric summary tables, comparison tables, ablation tables, dataset statistics tables, complexity tables.

Three Core Figure Types in Papers · Paradigm Quick Reference (borrowing the paradigm library idea from figure-designer, so that planning outputs land on specific paradigms rather than "put a figure")

When planning these three types of figures, directly attach a paradigm + layout skeleton, rather than vaguely "suggest placing a method figure":

Motivation/problem figure (intro): Paradigm = "pain-point comparison" (left: current-state flaws vs. right: this paper's improvement) or "concept illustration" (making an abstract problem concrete). Layout: side-by-side or a single large illustration; place at the end of §1. Common mistake: cramming in too much detail, showing the method too early.
Method overview figure (method): Paradigm = "pipeline flow" (input→module→output, with arrows marking data flow) or "architecture diagram" (module stacking + connections). Layout: horizontal pipeline (narrow aspect ratio, suitable for the top of a two-column page) or vertical; highlight innovative modules with accent colors/dashed boxes. Tools: Draw.io/TikZ, not AI-generated images. Place at the start of §3.
Results figure (results): Paradigm = "grouped bars + error bars" (comparison of multiple methods across multiple datasets) / "line + confidence band" (trend/convergence/sensitivity) / "scatter + regression" (correlation) / "heatmap" (matrix/ablation grid). Layout: main results as a single large figure, secondary ones in grouped panels. Must include error bars + significance + n.recommend_chart.py Specific paradigms can be recommended based on the data form of the claim.

Paradigms are only a starting skeleton; the final choice is determined by the claim and the data. Reference sample pool: you can attach links to high-quality figures of the same kind (e.g., dair-ai/ml-visuals templates, awesome-scientific-figure) as planning references, butpaper data figures must be drawn programmatically using real data; do not copy them and do not generate them with AI。

Quick tool-selection reference (write into the "recommended tools" field of the planning card)

Statistical/quantitative figures: matplotlib (finest control), seaborn (automatic CI/faceting), ggplot2 (R's grammar of graphics), Plotly/Altair (interactive + static export).
Signal/control/numerical simulation figures(spectrum/FFT, Bode/root locus, Simulink simulation output): MATLAB (native to the Signal/Control toolboxes,exportgraphics outputs vector graphics)—especially when the project is already in the MATLAB ecosystem; there is an official MATLAB MCP Core Server (runs local MATLAB, see the README's recommended MCP table for configuration), and the execution-side m11 figure-drawing already supports it; for this type of figure, filling MATLAB into the "recommended tools" field of the planning card closes the loop.
Publication-grade vector graphics, many formula labels: TikZ/PGFPlots, from the same source as LaTeX, with seamless fonts and formulas.
Framework/system diagrams, requiring an editable vector source：diagrams.net/Draw.io（.drawio i.e., mxGraph XML, which can be modified programmatically in batches and put under Git version control; there areofficial MCP jgraph/drawio-mcp and the community lgazo/drawio-mcp-server, which allow AI to generate/edit .drawio; CLI drawio --export --format pdf/png/svg batch figure generation, note version locking when scripting, see references for details).
Relationships/dependencies/automatic layout: Graphviz (dot hierarchical; neato/fdp spring; sfdp large graphs).
In-document sketches/flows: Mermaid (natively rendered in GitHub/Notion, diagram-as-code).
3D scientific visualization/structure/molecules: Blender (open source and free, programmatic modeling and renderingnot AI-generated images; there are the community ahujasid/blender-mcp and the Blender Foundation's official Lab MCP).A mature research approach is to directly use specialized add-ons: Molecular Nodes (proteins/PDB/trajectories), SciBlend (scientific data visualization), AstroBlend (astronomy);using MCP to let AI drive these scientific visualizations via natural language is still rarely practiced, belongs to the exploration direction. When 3D rendering is used as a figure for a paper, data authenticity and reproducibility must be ensured (clearly specify rendering parameters/data sources); otherwise it is more suitable for pitch decks/showcases (→ m16 slides). If professional icon libraries are needed for life science pathway/mechanism schematics, SaaS such as BioRender can be used manually (its official MCP only queries and cannot create figures, so it is not listed as a programmatic path).
Final multi-panel layout/manual vector fine-tuning of already exported figures: Inkscape (free, CLI inkscape in.svg --export-type=pdf,svg, convert text to outlines --export-text-to-path) or Adobe Illustrator (industry standard,.ai proprietary non-open format, save as PDF/SVG across tools). Freely align and assemble heterogeneous panels (mpl-exported PDF + bitmap + text labels) into a single submission figure.

Publication-level hard specifications (execution is constrained accordingly in the planning card)

Resolution/format: line art vector (PDF/EPS/SVG) or 600–1200 DPI; bitmap 300–600 DPI, TIFF/PNG,never use JPEG to store scientific data. Set matplotlib pdf.fonttype=42 to avoid Type-3 fonts being rejected.
Color scheme: use Okabe-Ito for discrete (#E69F00 #56B4E9 #009E73 #F0E442 #0072B2 #D55E00 #CC79A7), viridis/plasma/cividis for continuous quantities; add redundant encoding beyond color (line style/marker);test both grayscale + color blindness。
Font: sans-serif (Arial/Helvetica), labels in sentence case, units in parentheses.Minimum font size is determined by the journal, do not apply one-size-fits-all: Nature's official measured lower limit 5 pt(Nature only, ✅ curl www.nature.com hit 5–7 pt verbatim), butthe general safe lower limit for most journals is 6–7 pt(many plotting tools by default suggest 6–8 pt)—unless you confirm the target journal allows it,do not go below 6 pt, use 5 pt only when you have confirmed it is Nature. Judge at the final print size.
Column width(set figure width in mm according to the target journal;the following numbers are only a snapshot; at runtime the sole source of truth is light-figure-drawing figure_export.py 's JOURNAL_SPECS—before generating figures, rely on what the script dynamically reads; if the numbers in this table disagree with it, the script prevails; last synchronized 2026-06-11. The values below are only curl-measured for Nature; other publishers' official websites return 403 paywalls to curl/WebFetch, so they are common values from public author guidelines; before submission, always defer to the target journal's official website):
- Nature(✅ curl measured www.nature.com/nature/for-authors/final-submission，HTTP 200): single column 89, double column 183, maximum height 170(leave space for the caption).
- Science (AAAS)(column width numbers use light-figure-drawing figure_export.py JOURNAL_SPECS as the sole source of truth; the three-tier system was verified online from multiple sources on 2026-06-11): single column 55(5.5 cm), double column 120(12 cm), full page 183(18.3 cm). Note that Science does not have a "175" tier.
- Cell Press(⚠️ paywall not measured): single column 85, 1.5 column 114, full page 174. Note that full page is 174, not 178.
- PLOS(✅ curl measured journals.plos.org/plosone/s/figures, HTTP 200): single column 83, 1.5 column 140, full page 190; accepts only TIFF/EPS, 789–2250px@300dpi, height ≤2625px, font Arial/Times/Symbol 8–12pt, single file <10MB. Column width numbers use figure_export.py（light-figure-drawing）JOURNAL_SPECS the plos key is the single source of truth.
- Elsevier(⚠️ paywall not empirically tested; includes db01's Computers and Electronics in Agriculture, etc.): minimum 30, single column 90, 1.5 column 140, double column/full page 190。
- IEEE(⚠️ paywall not empirically tested, IEEEtran two-column layout): single column ≈88.9(3.5 in), double column/full-page text width ≈181.9(7.16 in)。
- MDPI(⚠️ paywall not empirically tested, includes db01's Animals): single-column layout body text width ≈170, figures should be laid out at this width or an integer fraction thereof; line art/composite figures are recommended at 1000 DPI, photographs ≥300 DPI.
- Chinese journals(✅ 2026-06-11 empirically measured from published PDFs, pdfplumber word-edge clustering, already recorded in db01 risk_note):Transactions of the Chinese Society of Agricultural Engineering single column ≈86, full page ≈180(A4 two-column);Scientia Agricultura Sinica、Acta Agronomica Sinica single column ≈81, full page ≈170(A4 two-column);Transactions of the Chinese Society for Agricultural Machinery PDF entry is blocked by anti-scraping, markedto be verified. Chinese journals are not in JOURNAL_SPECS, use the journal="custom", custom_width_mm=<db01实测值> escape channel to export figures.
- Export sizes are set in mm (e.g., ggplot2 ggsave(w,h,units='mm',dpi=300)、mpl figsize conversion).
Statistical rigor: must include error bars (SD/SEM/CI, noted in caption), sample size n, significance markers, and plot scatter points where possible.
Multiple panels: matplotlib GridSpec / subplots; bold uppercase A/B/C labels; consistent style and scale across panels.
- Anti-redundancy (the core test for panel groups): each panel must answer aunique scientific question—cover any one panel and it should create an information gap that cannot be filled in from the other panels. Two panels using different graphics to answer the same question is redundancy. Common redundancy traps: ① the same data plotted as an "absolute value bar" and also as an "absolute value table"; ② one panel is a subset/superset of another; ③ two ranking plots conveying the same ordering information. If redundancy is found → merge, delete, or switch to a perspective that can answer a new question (e.g., change the second absolute value plot to "deviation from baseline").
- Recommended information progression for multiple panels: overview (panorama) → deviation (deviation/comparison) → relationship (variable relationships), supplementing layer by layer rather than repeating.

db07 lookup discipline and planning card boundaries

Look up db07 canonical first: for general chart patterns look up databases/db07-figures/resources_real.md; for advanced/domain-standard charts look up databases/db07-figures/figure_advanced_cards.md；figure_cards.md retains only templates + canonical index,no more entity cards may be written。
Filter subject-specific cards by research_field: first read the project direction (db09 project card domain), and according to the research_field controlled value table in the db07 README, select cards only from the two sets 通用 + matched domain-specific chart types (e.g., GWAS→Manhattan, survival analysis→KM, methodology comparison→Bland-Altman); do not push subject-specific cards such as volcano/CONSORT to users not in that direction; when the project direction is missing, degrade to no filtering and use the full candidate set.
replication_notes references iron rule numbers: The planning card's color_scheme/replication_notes directly reference the db07 README "Figure Methodology Iron Rules R1-R9" numbers (e.g., "follow R1/R8"), no longer restating the general honesty rules in each card, maintaining a single source of truth.
db07 is a reusable figure pattern library: only accumulate cross-project general figure_card. A specific paper's F1/F2, caption, target journal, and export file paths are project-level artifacts, written to the repository root's databases/db09-projects/projects/<project_name>/version_history.md and projects/<project_name>/figures/manifest.md, not stuffed directly back into db07.
Selection order: first map each claim to an existing canonical figure_type; if there really is no match, then plan to add a new reusable figure_card to resources_real.md or databases/db07-figures/figure_advanced_cards.md, and keep figure_type unique across the whole library.

Planning card for each figure/table (handed to m11 for execution)

Fill in one per single figure/tablePlanning card(for figures use templates/figure_plan_card.md，for tables use the dedicated templates/table_plan_card.md—tables have their own row/column structure/header grouping/alignment/significant digits/booktabs three-line table fields; the figure card's color_scheme/layout/GridSpec are meaningless for tables, don't share them). The planning card has two layers, to avoid mistakenly writing project execution fields as the db07 schema:

db07 base fields (can be accumulated as figure_card)：figure_type, paper_source, research_field, purpose, data_required, layout, color_scheme, annotation_style, caption_style, possible_code_tool, replication_notes, where_to_place_in_paper。
Project execution auxiliary fields (only go into the planning deliverable/manifest, not as db07 required schema)：figure_id, priority, target_journal, column, caption_draft, output_formats, source_card。

figure_id: fixed F# named figures,T# named tables (F=Figure, T=Table, e.g., F1/F2/T1), aligned with the m07 paper template's [图位 F1]/[表位 T1] placeholders, serving as the anchor for figure↔figure number↔caption.
source_card (required): records the hit db07 canonical source, e.g., databases/db07-figures/resources_real.md::跨数据集主结果对比(分组柱+误差棒), for m11 to execute per the card and for later traceability; only when confirmed as a brand-new figure pattern, mark source_card: new_canonical_candidate -> databases/db07-figures/resources_real.md(or databases/db07-figures/figure_advanced_cards.md) and later write back to db07.
target_journal: target journal key, take one of the figure_export.py(light-figure-drawing) JOURNAL_SPECS keys:nature/science/cell/plos/ieee/elsevier/mdpi. Determines the physical column width mm, minimum font size, preferred format; the execution skill passes save_for_journaldirectly based on this, avoiding the entire figure's physical size being invalidated by column-width guesswork. For out-of-list journals (e.g., Chinese journals) fill in target_journal: custom and add custom_width_mm: <mm>in the planning card (data must have a source: db01 card or measured record,guessing prohibited), and the execution end uses the save_for_journal(..., journal="custom", custom_width_mm=...) escape hatch.
column: column width tier, take single/double/full/onehalf(must be a key that actually exists for that journal in JOURNAL_SPECS :full only science/mdpi;onehalf only plos/elsevier).target_journal: custom When column is omitted, directly use custom_width_mm as the standard. Recommended tool: choose one of two: heterogeneous panel combinations (code figure + bitmap + text labels) / need pixel-by-pixel alignment and free fine-tuning → manual vector editing (Inkscape/Illustrator); same-source same-type data figures, pursuing reproducibility → code generation (GridSpec/subplots). For concept/schematic types, you can first produce ASCII wireframe + copy + color scheme + icon/chart type suggestions(content-first blueprint), lock down the information architecture before handing off for execution.

Reviewer-perspective self-check

Does every core contribution have figure/table support?
Are there any figures that are "pretty but convey no information"? Delete them.
Can the table be made more intuitive with a diagram?
Is the multi-panel logic clear (same-category alignment, consistent scale)?Each panel answers a unique scientific question, with no redundancy(Would covering one panel lose unique information)?
Can the caption be understood independently of the main text?
Schematics are scored on 5 dimensions (0–2 each, total 10):Scientific accuracy / clarity and readability / label quality / layout and composition / professionalism; journal-level target ≥8.5.Scope: limited to schematics/concept diagrams/framework diagrams, where composition is subjective(scoring derived from the community AI image-generation skill);For code-based vector data figures (bar/line/scatter/heatmap), use objective QA items instead(vector format, font size meets the column-width minimum, colorblind-safe, honest axes without truncation, error bars + n, self-consistent caption—see the 13-point pre-submission checklist below), and don't apply composition-aesthetics scoring to data figures.
14-point pre-submission checklist: resolution · format · dimensions · readability · colorblind-safe · grayscale-compatible · axis labels (including units) · error bars · panel labels · significance markers · clear legend · consistent fonts · remove decorative elements ·total number of display items ≤ target venue limit(count F#+T#, and if over, decide by "deletable → can be moved to appendix").

Before handing off to m11: contract validation (machine-checkable, reject early)

Hand the planning card to m11 for executionbefore, run scripts/validate_plan_card.py <卡.md>... to perform contract validation, catching at the planning stage the issues m11 would reject:

Validate that target_journal hits the figure_export.py JOURNAL_SPECS key (or custom with custom_width_mm）、column is an actual tier for that journal,figure_id is in the form F#/T# and unique across the batch (aligned with the m07 placeholders),source_card is required.
The scriptdynamically reads JOURNAL_SPECS from m11's figure_export.py(single source of truth, preventing column-width key drift); if it cannot be imported, fall back to the built-in snapshot and mark [SNAPSHOT]。
Only after everything passes (exit 0) hand off to m11; if there is a ✗, fix the card first per the prompt. This only validates machine-checkable contracts (key existence/complete fields/uniqueness) and does not replace quality judgment of the figure itself.

Handoff

The planning card is handed to m11 for drawing; stay in sync with m07/m08 to ensure text-figure consistency. Project-level style, figure numbers, captions, and export paths are registered in the repository root under databases/db09-projects/projects/<project_name>/version_history.md and projects/<project_name>/figures/manifest.md; only new figure/table patterns reusable across projects are written back to the db07 canonical file. Full-document figure/table style is maintained by a07.

Code legend (quick reference table when away from the full Light suite)

Code	What it is	Interface with this skill
m02	data-engineering	Supplies data; derived datasets are built back into it
m06	result-analysis	Supplies results/claim/claim_evidence_table (the numerical source for figures)
m07 / m08	paper-drafting / polishing	Supplies `[图位 F1]`/`[表位 T1]` placeholders, keeping text and figures consistent
m11	figure-drawing	Downstream execution end: draws figures per the planning card; its figure_export.py JOURNAL_SPECS is the single source of truth for column width/font size
m12	typesetting	Executes booktabs formatting for tables
a07	consistency	Maintains full-document figure/table style consistency
db01	Journal library	Target journal and measured column width
db07	Figure/table library	Reusable figure_card pattern library
db09	Project library	Register project-level drawing number/caption/export path/version_history

For the tool's actual endpoints, API parameters, usage of each plotting library, and known pitfalls, see references.md。