Squib compiles a card game deck from Ruby code

Squib replaces hand drawn templates with a deck script

Squib exists to remove the drudgery of card template editing. The common workflow for prototyping a card game is to lay out one template, duplicate it dozens of times, then reopen each duplicate whenever the layout changes. Squib turns that into a program: you write a little Ruby, declare the deck's stats, and the tool compiles the deck into images. The README frames the output as ready for print-and-play or even print-on-demand, so the target user is a designer iterating on a game rather than a studio preparing a finished product. Two details narrow the audience further. First, everything is expressed in Ruby, so the tool rewards programmers and punishes people who want a point and click interface. Second, the emphasis is on the dry principle, so the payoff grows with the size of the deck. A two card prototype is quick to write by hand, but a hundred card deck with variants is where a data driven generator starts to matter.

The rendering stack is Cairo underneath, with Pango for text

The interesting part of Squib is not the DSL surface but the rendering chain underneath it. Squib is built on the Cairo graphics rendering engine, the same library used by WebKit, Gecko, and Inkscape. Text is handled separately through Pango, which means Squib can do complex text rendering rather than simple single font stamping. That combination is what allows a layout file to describe things like font, size, color, and alignment for every slot. Around that core, the project lists loading PNGs and SVGs, basic shape drawing, blending operators, gradients, unit conversion, and reading of xlsx and csv files. Output can be rendered to PNG, PDF, and SVG, either as sheets or as individual files. Data does not have to live in the script. Layout arguments can sit in a YAML file, and custom colors are defined in config.yml rather than being hardcoded as magic strings in the code. The practical consequence is that a designer can iterate on geometry in a text editor instead of opening a graphics package.

Scaffolding a project and running your first deck

Squib requires Ruby 3.0 or later. The gem is published under the name squib, and the README offers both a direct install and a Bundler route:

$ gem install squib

If you use Bundler, the README shows the manifest line and the follow up command:

gem 'squib'

$ bundle

Once the gem is present you can scaffold a project with the new command and run the generated script:

$ squib new my-cool-game
$ cd my-cool-game
$ ruby deck.rb

The generator produces a twelve file tree that includes deck.rb, layout.yml, config.yml, a Rakefile, and several Markdown notes files for rules, playtesting, and ideas, along with an _output directory for rendered files. The smallest possible build, straight from the README, shows the shape of every Squib script. You create a deck with a card count, place a text command on it, and save the result as PNG:

require 'squib'

Squib::Deck.new(cards: 2) do
  text str: %w(Hello World!)
  save_png
end

Ranges and arrays collapse the repeated text command

The strongest documented feature is the range parameter on the text command. A single text call can carry different strings, fonts, styles, and colors for different cards, using Ruby arrays and range objects rather than one call per card. The README is blunt about the intent: if you find yourself issuing multiple text commands for the same field across different ranges of cards, there is probably a better way to condense it. The same thinking shows up in layouts, where a special extends mechanism works well for grouped styles, and in config.yml, where named colors replace repeated color strings. Together these features explain the project's positioning. Squib is not a general graphics library with a card theme on top. It is a way to write a deck once and let the compiler expand it, and the payoff depends entirely on how much repetition your game contains.

The Docker image mounts your working copy and nothing more

An official image is published on DockerHub under the name andymeneely/squib. The documented invocation maps the current directory to /usr/src/app inside the container so that files read and written by the script land back in your working copy. The macOS form of the command is below, and the README gives a separate form for Windows:

docker run --rm -v "$PWD":/usr/src/app andymeneely/squib ruby hello.rb

After it runs, an _output folder appears in your current directory holding the rendered files. The image itself is built from ruby:3.2-slim and installs a long list of system packages, including librsvg2-dev, libgdk-pixbuf2.0-dev, build-essential, and fonts-open-sans. That dependency list is the clearest signal of what Squib actually needs from a machine: a Ruby runtime plus a native SVG and text rendering stack.

Where Squib is the wrong tool

Three limits are visible in the documentation itself. First, this is a prototyping tool, not a game engine. Nothing in the project simulates rules, tracks state, or validates a deck, so it cannot tell you whether a game is balanced. Second, the output path depends on a system graphics stack, and fonts are a specific hazard, because a layout that names a font only renders correctly where that font is installed. The Docker section notes that custom fonts are still an open problem for custom builds, so teams with pinned typefaces should assume extra work. Third, the container workflow is not fully settled. The README states that ways to customize your own Docker build, such as document building and custom fonts, are still being worked on. The samples directory shows the shape of the wider tool, with folders for colors, layouts, ranges, units, proofs, sprues, and shadows, but it is a collection of examples rather than a published pipeline.

How Squib differs from a template and image editor

The README compares Squib to nanDeck, describing it as nanDeck done the Ruby way. The difference is not cosmetic. A point and click editor stores your card as a document you click through, while Squib stores your card as source code that a Ruby interpreter runs, so every change is versionable, diffable, and repeatable. The other alternative worth naming is writing your own Cairo and Pango script directly. Squib removes that work and adds a layout system, but it also imposes its own vocabulary of layouts and ranges on you. If your deck needs graphics behavior that the DSL does not expose, you end up fighting the tool. If it needs only data driven templates, Squib saves you the entire build layer and the maintenance of it.

The licence is permissive, but the release trail is thin

Squib is released under the MIT licence, which permits commercial use, modification, and redistribution provided the notice is retained. That is about the only part of the maintenance picture that looks settled. The last push to the repository was on 2026-04-07. The most recent tagged release is v0.19.0 from 2023-04-09, described only as dependency fixes, with v0.17.0 in 2021 and v0.16.0 in 2020 before it. The default branch is dev, and the repository contains a CHANGELOG, a CONTRIBUTING file, a Dockerfile, a docs directory, a spec directory, and a benchmarks directory. The gap between the last release and the last push means you should treat the project as one you own rather than one you wait on. Read the CHANGELOG for what changed after v0.19.0, pin your gem version, and expect to carry the Cairo and Pango dependency chain yourself.

Editorial conclusion

Squib earns a place on the desk of a designer who already works in Ruby and needs the deck recompiled every time a card changes. It is the wrong choice for a team that wants a playable rules simulation, a browser based editor, or a maintained release stream, because no release has shipped since v0.19.0 on 2023-04-09 and the last push was on 2026-04-07. Before adopting it, verify that your printers accept the SVG and PDF output, that every font named in your layout is installed on each machine that runs the build, and that you are willing to own the Cairo and Pango dependency chain yourself.

Frequently asked questions

Official sources

1. andymeneely/squib on GitHub
2. License: MIT
3. Project website
4. README
5. Releases