A new member has joined the fulgur family.
fulgur-chart — a CLI that takes Chart.js v4-compatible JSON specs and renders deterministic SVG/PNG charts. No browser required.
https://github.com/fulgur-rs/fulgur-chart
Two things make it different: it doesn't spin up a browser, and for a fixed version, font, and rendering options, the same JSON input always produces byte-identical output.
This post covers why I built it, a timing coincidence that made me feel like I was on the right track, and how to use it.
Why I wanted graphs in PDFs
fulgur and fulgur-chart are built around one idea: AI agents should be able to generate documents that look good.
There are three steps to that argument.
First, Markdown isn't expressive enough. For client-facing reports, plain Markdown often undersells otherwise strong content.
Second, visual quality is persuasive. A well-formatted report lands differently than a wall of text.
Third — and this is the one I keep coming back to — in many business workflows, PDF carries more institutional weight than a Markdown file or a transient web page.
That authority has two dimensions. There's a cognitive one: PDFs read as "serious documents." Proposals, reports, invoices — the format itself signals credibility. And there's a technical one: PDF can support digital signatures, encryption, and archival profiles such as PDF/A. That's the ground flpdf covers, a pure-Rust PDF toolkit modeled on qpdf's workflow.
So the goal is always PDF, not HTML, not a web page. That's what fulgur is for.
And a polished report needs charts. But Markdown can't draw charts.
Which brings me to a problem I already knew was coming: the Chart.js library requires JavaScript to run.
fulgur has no browser and no JS runtime, so there was no path to running Chart.js directly.
The design choice: no JS engine
The obvious alternative was to embed a JavaScript runtime. I could either run Chart.js with a compatible Canvas implementation, or build a JavaScript renderer that consumes Chart.js-style specs and emits SVG directly. Both approaches can be browser-free, offline, and deterministic.
But I wanted fulgur-chart to remain a Rust-only, data-only pipeline, with no JavaScript runtime and a smaller behavioral surface to audit and maintain. So I chose to interpret a supported subset of Chart.js-compatible JSON directly in Rust.
fulgur's philosophy is built on five pillars:
- No browser required — no Chromium, no WebKit, no headless anything. Single binary, fast cold starts.
- Low memory footprint — designed for server-side batch processing. Won't eat your container's memory limit.
- Deterministic output — same input → byte-for-byte identical PDF, every time.
- Template + JSON data — HTML templates with JSON data for bulk generation. MiniJinja engine built in.
- Offline by design — no network access. Fonts, images, CSS — everything explicitly bundled.
fulgur-chart inherits this posture. Accepting arbitrary plugin code or dynamic callbacks would make the behavioral surface harder to reason about and test. The static, data-only design keeps it auditable.
To make the output truly deterministic, I scoped down the input: arbitrary plugin code, callbacks, and animations are excluded. fulgur-chart is data-only and fully static.
Fonts are bundled too. Noto Sans JP is included so text rendering never depends on the host system. Change the machine and the output stays the same.
Good-looking output. Deterministic output. I chose to chase both.
As a side effect: charts committed to git never show spurious diffs, and re-generating in CI is always safe.
The day after I started designing it, Artifacts shipped
Now for the coincidence.
I committed the initial design document for fulgur-chart on June 17, 2026.
The next day — June 18 — Claude Code Artifacts was announced.
Artifacts lets Claude Code generate rich, interactive reports as outputs: PR walkthroughs, dashboards, security reports, cost analyses. Currently in beta for Team and Enterprise: the output is a live, interactive web page viewed in a browser.
When I saw it, my immediate reaction was: this is exactly the world fulgur is building toward.
The belief I'd been acting on — that Markdown isn't good enough, that visual quality matters, that AI agents should produce proper-looking documents — felt like it had just received an independent signal from Anthropic itself. The timing didn't prove the design, but it was encouraging.
The directions are different: Artifacts goes toward the Web, fulgur goes toward PDF. Authority, determinism, offline-first. But the underlying conviction is the same: good output matters, and Markdown isn't good enough.
The contrast actually sharpened fulgur's position rather than blurring it.
And for good-looking PDF reports, you need charts. That's what fulgur-chart is for.
Usage
Basic usage is simple:
# Generate SVG from a JSON spec
fulgur-chart render chart.json -o chart.svg
# PNG at 2x resolution
fulgur-chart render chart.json -o chart.png --format png --scale 2
# Pipe mode (use - for stdin/stdout)
cat chart.json | fulgur-chart render - -o - > chart.svg
# Batch: process multiple specs
fulgur-chart render specs/*.json --out-dir out/
# Specify dimensions and use strict mode
fulgur-chart render chart.json -o chart.svg --width 1024 --height 576 --strict
Key options:
--format svg|png-
--width <px>/--height <px> --scale <factor>--font <path>--out-dir <dir>--dsl chartjs|vegalite--strict
The input uses the familiar shape of a Chart.js v4 config. fulgur-chart implements a data-only, static subset: common chart data and selected options work, while callbacks, interactions, and arbitrary plugin code are intentionally excluded.
{
"type": "bar",
"data": {
"labels": ["Jan", "Feb", "Mar"],
"datasets": [
{ "label": "Revenue (k$)", "data": [120, 200, 150], "backgroundColor": "#36a2eb" }
]
},
"options": {
"plugins": { "title": { "display": true, "text": "Monthly Revenue" } }
}
}
Options like options.plugins.title work as expected. In CI, use --strict so unsupported options fail loudly instead of being silently ignored.
Supported chart types
QuickChart is the closest reference point in terms of input format and chart coverage. It can also be self-hosted; fulgur-chart makes a narrower bet on a single local binary, data-only input, no JavaScript runtime, and deterministic output.
As of v0.1.x, the supported chart types are:
- Bar chart (vertical/horizontal — use
options.indexAxis: "y"for horizontal) - Stacked bar chart
- Line chart
- Area chart
- Pie chart / Doughnut chart
- Scatter plot
- Bubble chart
- Radar chart
- Mixed chart
- Matrix / heatmap
- Box plot
- Gauge / Radial gauge
- Progress bar chart (QuickChart-compatible)
The progress bar chart is worth calling out. It's a QuickChart original: datasets[0].data sets the bar values; an optional second dataset's data overrides the max per bar (default is 100). Percentage labels are on by default — set options.plugins.datalabels.display: false to hide them.
The --dsl vegalite flag also accepts a Vega-Lite subset if you prefer that format.
How it's implemented
Reproducing Chart.js's visual output without a browser is more work than it sounds.
Layout, axes, legends, text measurement — everything the browser was handling silently has to be done from scratch. Text measurement in particular is critical for determinism: if that drifts, the output drifts. Bundling Noto Sans JP and doing all measurement against that removes the environment as a variable.
For a fixed fulgur-chart version, font, dimensions, and output format, the output is byte-identical across runs and machines. You can verify this in CI:
fulgur-chart render chart.json -o first.svg
fulgur-chart render chart.json -o second.svg
sha256sum first.svg second.svg
# both hashes should match
Architecturally, there's a layered design: DSL frontend → intermediate representation (IR) → rendering core. Adding support for a new input dialect (Chart.js, Vega-Lite, or eventually others) means adding a frontend that maps to the IR, without touching the renderer.
Development is Rust + AI-driven: Claude Code with superpowers, following a brainstorm → plan → implement cycle. Same approach I've been using for fulgur core — I wrote about that workflow here.
Embedding charts into fulgur PDFs
The original motivation was getting charts into PDFs.
The workflow: render an SVG with fulgur-chart, embed it in HTML with <img>, then pass the HTML to fulgur. The examples/report.html in the fulgur-chart repo shows a working example.
Font consistency matters here. Bundle the same Noto Sans JP in fulgur, and chart text glyphs will match the rest of the PDF exactly — no font mismatch between chart labels and body text.
That closes the loop:
AI agent → deterministic PDF report, with charts, looking polished, offline.
Where it is now and what's next
As of June 2026, fulgur-chart is still v0.x — young, but the core chart types work.
The immediate roadmap includes a few gaps in the current implementation:
- Value labels on radar chart axes, data labels for scatter/radar
- Dual-axis mixed charts
- Vega-Lite
transform,aggregate, URL data sources (currently inlinedata.valuesonly) - Font subsetting to reduce binary size
Longer term, I'm thinking about:
- More chart types — expanding toward full QuickChart coverage
- More input formats — Graphviz and others in QuickChart's scope
- Jsonnet support — programmatic spec generation
- Server mode — run as a persistent API, QuickChart-style
- Agent skill — expose chart generation as a direct tool call for AI agents
The destination: QuickChart-equivalent coverage, browser-free, deterministic, and ready for AI agents to call directly.
Wrapping up
The fulgur family keeps growing:
- fulgur — HTML → PDF
- flpdf — pure-Rust PDF toolkit modeled on qpdf
- fulgur-chart — deterministic chart generation
All of them are projects I intend to keep building for a long time.
If any of this sounds useful, give it a try.