Ieee Figure

IEEE Figure Making Skill

A guide for producing IEEE-ready scientific and engineering figures as clear visual evidence, not isolated decorative plots. Every figure starts from a claim, an evidence hierarchy, the target IEEE column width, and an export/print check before code or aesthetics.

The older Python/matplotlib rules in this skill remain valid. The skill also supports R, especially ggplot2 + patchwork + ComplexHeatmap + ggrepel + svglite/cairo_pdf + ragg. If the user provides a private plotting template collection, use it only as an internal adaptation source and do not reveal its path, filenames, or provenance in user-facing output.

Color policy: prefer clear engineering contrast and grayscale-safe encodings. Do not rely on color alone; pair color with line style, marker shape, direct labels, outlines, or ordered luminance when the figure may be printed in black and white. Do not use interior textures/hatching by default; use them only when the user explicitly asks or when grayscale distinctions cannot be made by cleaner encodings.

First move: figure contract before plotting

Before generating or editing code, establish the contract below.

Backend selection is a blocking gate. If the user has not explicitly chosen Python or R in the current request or provided a clearly language-specific input file/workflow, ask one concise question: Python or R? Then stop and wait for the user's answer. Do not generate mock data, write scripts, create figures, or choose Python/R by default. This overrides general autonomy/default-execution behavior for figure tasks.

The selected backend is exclusive for all figure generation. Once Python or R is selected, every plotting script, preview image, EPS/PDF/SVG/TIFF/PNG export, QA render, and visual workaround must be produced by that same backend. Do not use Python to draw a preview for an R figure, and do not use R to draw a preview for a Python figure, even if the selected runtime or packages are missing locally. The non-selected language may only be used for non-visual file inspection or data conversion when it does not open a graphics device, import plotting libraries, create image/vector files, or change the final visual appearance.

Missing runtime/package rule. After the backend is selected, check the selected runtime early (Rscript/R for R; Python and required plotting packages for Python). If the selected runtime or required packages are unavailable, stop before rendering and report the exact blocker. You may provide a selected-backend script and installation commands, or ask permission to install dependencies, but you must not fall back to the other language to make a substitute figure.

Only recommend a backend when the user explicitly asks you to choose or recommend one. In that case, use references/backend-selection.md, state the reason, and then proceed with the recommended backend.

1. Core conclusion: write the one-sentence claim the figure must defend.
2. Evidence chain: map each planned panel to the claim, and drop panels that do

not carry a unique piece of evidence.

1. Archetype: classify the figure as quantitative grid,

schematic-led engineering composite, image/field map + quant, or asymmetric mixed-modality figure.

1. Backend: use the selected Python or R track exclusively for all figure drawing,

previewing, exporting, and visual QA. Do not cross-render with the other language.

1. IEEE/export contract: set destination type, final column width, readable text

after reduction, vector/raster boundary, source data, statistics, grayscale safety, accepted file formats, font handling, and export names before styling.

The highest-priority rule is: the chart serves the technical argument. Aesthetic polish, template matching, and complex layout are subordinate to making the core conclusion clear, defensible, reproducible, and readable at IEEE column width.

IEEE defaults

• Single-column width: 3.5 in / 88.9 mm.
• Half-column inset: use when explicitly requested for a compact plot, framework,

architecture, circuit, module, or flow diagram occupying a small manuscript region. Default starts are 1.7 x 1.7 in, with target width:height = 1:1. For plotted figures, keep the axes box/line frame approximately square as well.

• Double-column width: 7.16 in / 182 mm.
• Maximum ordinary submitted graphic size before compression checks:

7.16 x 8.8 in / 182 x 220 mm.

• Use the target column width from the destination template if it is supplied.
• Do not prepare graphics below one-column width unless the user explicitly asks

for a half-column inset/block diagram or provides a template slot. In that case, keep the normal font size and simplify geometry instead of shrinking text.

• Prefer vector output for line art and plots: PS, EPS, or PDF; SVG is

useful as an editable intermediate when the workflow supports it.

• Use PNG or TIFF for raster-heavy field maps, photos, microscopy, simulation

heatmaps, and previews.

• Resolution: color/grayscale raster at least 300 dpi; black-and-white line art

at least 600 dpi.

• Text: IEEE-listed fonts include Helvetica, Times New Roman, Arial, Cambria, and

Symbol. Type should appear about 9-10 pt at full size; use 8 pt only as a compact lower bound for dense labels that remain legible.

• Font handling: for EPS, PS, or PDF, embed fonts or convert text to

outlines; prefer embedding for editable source files.

• Multi-panel labels: IEEE commonly uses (a), (b), (c); keep labels

consistent, visible, and close to their panels.

• File naming: for final exports, use the first five letters of the primary

author's surname plus figure number when known, such as gonza1.pdf; otherwise use clear sequential names and flag naming as a final-submission item.

• Avoid unaccepted formats: VSD, GIF, BMP, and manuscript JPEG. High-resolution

JPEG is only for author photos.

• Color: ensure grayscale print remains interpretable. Use line styles, markers,

clean luminance contrast, outlines, and direct labels in addition to color. Avoid texture/hatching inside bars or filled regions unless explicitly requested.

• Axes: include units, define error bars, and align scales when panels invite

comparison.

• Scientific notation: render subscripts/superscripts with math text or the

selected backend's expression system. Never leave labels like P_on, R_th, V_g, I_d, or t_rise as raw underscore text in the final figure.

• Captions must define symbols, abbreviations, colors, line styles, and markers.
• Reused or adapted graphics need permission and citation notes.
• Do not use the Lena image in submitted IEEE figures.

Half-column inset and compact block diagrams

Use this mode when the user asks for a half-column figure, compact framework, architecture block, module diagram, circuit/data-flow schematic, or a figure that occupies a true half-column inset slot.

• Keep font size unchanged: target 9-10 pt full-size type, with 8 pt only for

dense but still readable labels.

• Keep a deliberate aspect ratio. If the user specifies only width, choose height

equal to width for half-column inset figures. For plotted figures, keep the axes box/line frame approximately 1:1, not just the outer canvas.

• Prefer fewer blocks and stronger hierarchy over shrinking the entire drawing.
• Use abbreviations only when the caption defines them.
• Use direct labels inside blocks when possible.
• If a legend is needed, place it intelligently in unused white space:

top-right, top-left, bottom-right, bottom-left, then outside-above/outside-below as fallbacks.

• Do not let the legend cover arrows, nodes, data, axis labels, scale bars, or the

visual path of the schematic.

• For block diagrams, reserve a small "legend bay" or empty corner during layout

instead of adding the legend after the diagram is crowded.

User-facing privacy rule

Do not disclose private local paths, private filenames, chat-attachment names, internal reference filenames, template identifiers, or the provenance of private working materials in user-facing replies, generated code comments, figure legends, reports, or manuscript text. Use generic descriptions such as "the provided R template collection", "a private working draft", or "the internal figure contract". Only reveal an exact path or source file when the user explicitly asks for that audit trail.

Python quick-start

Python-only execution rule. When the user has selected Python, do all figure drawing, previewing, exporting, and visual QA in Python. Do not call R/ggplot2, ComplexHeatmap, patchwork, or any R graphics device to create a temporary preview, fallback export, or layout approximation. If Python or required Python plotting packages are missing, stop before rendering and report the missing dependency. You may still write the Python script, provide pip/environment install commands, or ask permission to install dependencies, but do not cross-render the figure in R.

import matplotlib as mpl
import matplotlib.pyplot as plt

IEEE_SINGLE_COLUMN_IN = 3.5
IEEE_DOUBLE_COLUMN_IN = 7.16

mpl.rcParams.update({
    "font.family": "sans-serif",
    "font.sans-serif": ["Arial", "Helvetica", "DejaVu Sans", "sans-serif"],
    "svg.fonttype": "none",     # editable text in SVG
    "pdf.fonttype": 42,         # editable TrueType text in PDF
    "ps.fonttype": 42,          # editable TrueType text in EPS/PS when supported
    "font.size": 9,
    "axes.spines.left": True,
    "axes.spines.right": True,
    "axes.spines.bottom": True,
    "axes.spines.top": True,
    "axes.linewidth": 0.8,
    "axes.grid": False,
    "xtick.direction": "in",
    "ytick.direction": "in",
    "xtick.top": True,
    "ytick.right": True,
    "xtick.major.width": 0.8,
    "ytick.major.width": 0.8,
    "lines.linewidth": 1.0,
    "legend.frameon": False,
})

def save_ieee_py(fig, filename, dpi=600):
    fig.savefig(f"{filename}.pdf", bbox_inches="tight")
    fig.savefig(f"{filename}.eps", bbox_inches="tight")
    fig.savefig(f"{filename}.png", dpi=300, bbox_inches="tight")
    fig.savefig(f"{filename}.tiff", dpi=dpi, bbox_inches="tight")

Use text.usetex = True only when LaTeX is installed and math-rich labels are required by the paper.

R quick-start

library(ggplot2)
library(patchwork)

IEEE_SINGLE_COLUMN_IN <- 3.5
IEEE_DOUBLE_COLUMN_IN <- 7.16

theme_set(
  theme_bw(base_size = 9, base_family = "Arial") +
    theme(
      panel.border = element_rect(linewidth = 0.35, colour = "black", fill = NA),
      axis.line = element_blank(),
      axis.ticks = element_line(linewidth = 0.35, colour = "black"),
      axis.ticks.length = grid::unit(-1.5, "pt"),
      legend.title = element_text(size = 9),
      legend.text = element_text(size = 8),
      strip.text = element_text(size = 9, face = "bold"),
      plot.title = element_text(size = 9.5, face = "bold"),
      panel.grid.major = element_blank(),
      panel.grid.minor = element_blank()
    )
)

save_ieee_r <- function(plot, filename, width_in = IEEE_SINGLE_COLUMN_IN,
                        height_in = 2.6, dpi = 600) {
  grDevices::cairo_pdf(paste0(filename, ".pdf"), width = width_in,
                       height = height_in, family = "Arial")
  print(plot)
  dev.off()
  grDevices::postscript(paste0(filename, ".eps"), width = width_in,
                        height = height_in, family = "Arial",
                        horizontal = FALSE, onefile = FALSE, paper = "special")
  print(plot)
  dev.off()
  ragg::agg_png(paste0(filename, ".png"), width = width_in, height = height_in,
                units = "in", res = 300)
  print(plot)
  dev.off()
  ragg::agg_tiff(paste0(filename, ".tiff"), width = width_in, height = height_in,
                 units = "in", res = dpi)
  print(plot)
  dev.off()
}

Default operating stance

• Start by classifying the requested figure into one of five archetypes:

quantitative grid, schematic-led engineering composite, half-column block diagram, image/field map + quant, or asymmetric mixed-modality figure.

• If the user asks for a single chart, still identify its role in the manuscript

claim: architecture, mechanism, validation, comparison, robustness, ablation, sensitivity, or deployment relevance.

• Prefer compact, readable panels over page-filling visual drama; IEEE figures

often need to survive aggressive single-column reduction.

• Keep the background white for plots and diagrams; switch to black only for

microscopy, thermal/field-map image plates, or volume-rendering panels where that is the native visual convention.

• Prefer direct labels over legends when categories are spatially fixed or the

legend would force unnecessary eye travel.

• Keep one restrained palette per figure and add non-color encodings for print:

line style, marker shape, ordered lightness, outlines, or annotations. Avoid hatched/textured fills unless the user asks for them.

• Treat statistics, n, error-bar definitions, source-data traceability, axis

units, caption definitions, permission status, font embedding, file naming, and grayscale-readability notes as part of the figure, not as optional cleanup.

• When the user asks for IEEE-specific compliance, read

references/ieee-figure-guidelines.md before choosing dimensions and exports.

• When the user references figures4papers or the older

scientific-figure-making skill, treat this skill as the IEEE-adapted successor and open references/demos.md for bundled Python demo scripts.

When to load this skill

• Python or R figures for papers, slides, or reports targeting IEEE journals,

IEEE conferences, Transactions, Letters, or similar engineering venues.

• Requests involving **grouped bars, trend lines, heatmaps, radar plots,

multi-panel grids, simulation maps, device plots, ablations, comparisons, or PDF/EPS/PNG/TIFF/high-DPI** output.

• Any mention of "IEEE style", "IEEE figure", "publication figure", "paper

figure", "SCI figure", "figures4papers", "scientific-figure-making", "R plotting template", or "high-quality scientific plot".

• Requests to improve a figure's logic, aesthetics, panel layout, figure legend,

export quality, grayscale safety, or journal-readiness.

When NOT to load

• Plotly, Altair, Bokeh, or other interactive/web-first plotting.
• EDA-only plots without a publication target.
• Primary workflow is 3D, GIS, or non-scientific illustration tooling.
• Illustrator / Figma-first layout.

Related files

| File | Open when | |------|-----------| | [references/figure-contract.md](references/figure-contract.md) | Need to convert a user request into core conclusion, evidence hierarchy, panel map, and review-risk checks | | [references/ieee-figure-guidelines.md](references/ieee-figure-guidelines.md) | Need IEEE dimensions, export formats, resolution, font, panel-label, and grayscale rules | | [references/backend-selection.md](references/backend-selection.md) | User has not chosen Python/R, asks for a recommendation, or a mixed Python/R workflow is possible | | [references/r-workflow.md](references/r-workflow.md) | User chooses R or provides R scripts/templates/data | | [references/r-template-index.md](references/r-template-index.md) | Need to adapt a user-provided or private R template collection without exposing source paths | | [references/qa-contract.md](references/qa-contract.md) | Before final delivery, revision package, microscopy/blot figure, or journal-specific audit | | [references/design-theory.md](references/design-theory.md) | Typography, color theory, layout rationale, export policy | | [references/api.md](references/api.md) | Python PALETTE, helper function signatures, validation rules | | [references/common-patterns.md](references/common-patterns.md) | Python layout patterns: compact comparison panels, legend-only axes, image plates, asymmetric layouts | | [refere

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: Narroog
• Source: Narroog/research-skills
• License: MIT

Install and usage instructions live in the source repository linked above.