From Pixel to Pen: Building a Plotter Toolchain

I own a pen plotter, a machine that holds a pen and draws on paper, following vector paths with mechanical precision. It is a simple concept with a surprising consequence: it forces you to think about images differently.

A screen does not care how an image was made. Pixels are pixels. But a plotter draws lines. Every visual element must be expressible as a path, a sequence of coordinates that a pen can follow in one continuous motion. No fills. No gradients. No layers of transparency blended in a framebuffer. Just ink on paper, one stroke at a time.

This constraint turns out to be productive. Over the past year, I have built a set of tools that form a complete pipeline from idea to paper.

The Pipeline

Capture → Generate → Transform → Prepare → Plot
  VHS       GenerativeArt  Vectorize    Gantry
  Tracer    CityPlot       PPCT         / G-code

Each tool solves one problem. Together, they cover every path from concept to physical output.

Historically the final stages were split between SVGToolBox for SVG preparation and SVG2WaterColor for watercolor plotting. Both remain documented as earlier experiments. Gantry supersedes them as the active endpoint of the toolchain, combining SVG preparation, positioning, command generation and G-code output in one Java application.

Stage 1: Capture (VHS and Tracer)

The Vector Handwriting System captures my actual handwriting as replayable vector data. I draw each letter ten times; the system stores the variance and reconstructs text stochastically, picking different versions of each character, smoothing with Catmull-Rom splines, and connecting letters through captured ligatures.

The output is single-stroke SVG. The plotter draws it with a fountain pen, and the result is indistinguishable from handwriting because it is handwriting, just time-shifted.

Tracer is another capture tool. It starts from a reference image instead of letters. I trace sparse lines by hand, keep the pressure data, and save a project file that can later become input for Gantry. SVG is the current visual handoff. The more interesting future handoff is full capture data, because pressure may become Z-axis movement.

Use case: Personal letters, annotations on plotted artwork, signed editions, sparse photo-based line drawings.

Stage 2: Generate (Generative Art)

The generative art toolkit provides 22 algorithms for creating visual patterns from mathematical processes. Flow fields, reaction-diffusion, L-system fractals, strange attractors, Voronoi tessellations. Each produces clean, layered SVGs optimized for multi-pen plotting. The browser version is available as a desktop web app and as a mobile studio.

The interesting part is not any single algorithm. It is the parameter space. A flow field with 500 particles and moderate noise produces gentle, wind-like textures. The same algorithm with 50,000 particles and high turbulence produces something closer to wood grain or geological strata. The code is deterministic; the exploration is not.

Use case: Abstract art prints, pattern generation, algorithmic exploration.

Stage 2b: Generate from Data (CityPlot)

CityPlot takes a different input: geographic data instead of algorithms. It queries OpenStreetMap for streets, buildings, water, and parks within a radius, then renders them directly as layered SVG, scaled to paper dimensions, ready for the plotter.

Each feature type lives in its own SVG group, so multi-pen plotters can switch colors between layers. The output scales from a coaster-sized engraving to a wall poster without losing a single line.

Use case: Stylized city maps of personally meaningful places as plotter art or CNC engravings.

Stage 3: Transform (Vectorize, or stay manual with Tracer)

Sometimes the starting point is not an algorithm but a photograph.

Vectorize converts raster images into clean SVG line art using Canny edge detection and multiple tracing strategies: Douglas-Peucker simplification, skeleton tracing, potrace-style Bézier fitting. The skeleton strategy is particularly useful for plotters because it traces the centerline of shapes, producing true single-stroke paths instead of outlines.

Tracer is the slower route through the same problem. It does not guess the lines automatically. I draw them. That makes it less efficient and more useful when recognizability, minimalism and hand pressure matter.

Use case: Converting sketches and photos to plottable line art.

Stage 4: Prepare and Plot (Gantry)

The output from the generation and transform stages is technically SVG, but not yet optimized for physical plotting. Gantry bridges that gap and then drives the machine.

It replaces SVGToolBox as the SVG preparation step:

• Palette quantization maps all colors to an actual pen collection.
• Hatching converts solid fills to line patterns, because a plotter cannot fill areas.
• Path optimization reorders paths to minimize pen travel.
• Layer separation keeps multi-pen and multi-station jobs manageable.

Then it replaces the split between SVG2WaterColor and a Python driver:

• Fit, scale, rotate and mirror the drawing onto a physical bed.
• Convert SVG geometry into a command model.
• Simulate, stream G-code to a GRBL plotter, or export .gcode for later use.
• Optionally insert watercolor refill trips based on paint capacity and station coordinates.

Use case: The final bridge from screen-ready SVG to real marks on paper.

Stage 4b: Check the Physical Setup (PPCT)

PPCT is the calibration sheet for the unglamorous part of the process: the pen, paper, plotter and settings. It generates an A4 target with straight lines, tight spacing, hatching, curves, long paths and repeated pen lifts. The browser version lives at simiono.com/ppct.

Use case: Comparing pens and papers before wasting a good drawing on a bad setup.

Stage 5: Paint (Watercolor as an Optional Gantry Stage)

SVG2WaterColor explored how to extend the toolchain from pens to brushes. That idea now lives inside Gantry as an optional watercolor stage.

The core challenge is paint capacity. A brush loaded with watercolor runs dry after a limited distance. The system tracks how far the brush has drawn, automatically calculates split points within strokes, and inserts refill commands. The brush travels to a paint station, dips, and returns to continue the stroke.

Each color layer maps to a physical paint station at a known XY coordinate on the plotter bed. A digital twin in the GUI shows the plotting process in real time. Useful for testing station positions and capacity settings in mock mode before committing paint to paper.

Use case: Automated watercolor paintings, combining generative art with physical painting.

Why Build Your Own Tools?

The obvious answer is control. Commercial vectorizers make assumptions about what you want. They optimize for screen display, not for a pen that lifts and lowers thousands of times. Building your own tools means building for your own output medium.

But the real answer is understanding. When you write a rasterizer, you understand what a triangle is, not as a shape on screen, but as a set of scanlines, a sorted edge table, an area that can be computed without allocating a single object on the heap. When you write a Catmull-Rom interpolator, you understand what “smooth” means mathematically, not as a slider in a UI, but as a cubic polynomial constrained to pass through control points.

The tools become a medium in themselves. The constraints of single-stroke output, the accidents of ink flow, the deliberate choice of algorithm parameters. These are creative decisions, no different from choosing a lens or mixing a color.

The plotter does not make art. Neither does the code. The art is in the curation: knowing which parameters produce something worth putting on paper, and having the tools to get it there.

See also: Gantry, PPCT, VHS, Tracer, Generative Art, CityPlot, SVGToolBox, SVG2WaterColor, Vectorize, Primitive, Topographie der Kreativität