InvoicePrinter turns a hash or a JSON file into a PDF invoice

Three ways to use it: library, command line, server

InvoicePrinter is described as a server, a command line program, and a pure Ruby library to generate PDF invoices in no time. The choice of representation is yours: you can use Ruby or JSON as the invoice representation to build the final PDF. That single design decision is what makes the tool fit into an existing application rather than sit beside it. As a library you call it from a Rails controller or a background job. As a command line program you pipe or point it at data. As a server you run it as its own process and let it serve requests. The repository carries three separate gemspec files, invoice_printer.gemspec, invoice_printer_fonts.gemspec, and invoice_printer_server.gemspec, which is how the three entry points are packaged separately so you can depend on the part you need. The topic list on the project places it firmly in command line tooling and server use, with prawn named as an associated technology.

No styling, no calculation, no money formatting

The philosophy section is three bullets and each one is a decision you will feel later. Simple means no styling required, no calculation, and no money formatting, with the instruction to bring your own for the last one. Pure Ruby means no dependency on system libraries or browsers. Fast means you can render invoices on the fly during requests, which is the reason a lot of people end up here in the first place. The consequence of the no calculation and no money formatting line is the important one. InvoicePrinter will lay out a quantity, a unit price, a tax percentage, and a total, but it will not work out your totals and it will not turn 1234.5 into a properly formatted currency string. Your code does that before it hands the invoice over. For a team that already has a money library, this is a feature. For a team that wants a drop in billing component, it is a gap you will notice immediately.

The layout is a fixed set of boxes and a configurable items table

What you get for the layout is a defined vocabulary rather than a template engine. The feature list names A4 and US letter paper size, an invoice or document name and number, purchaser and provider boxes with addresses and identification numbers, a payment method box showing banking details including SWIFT and IBAN fields, an issue and due dates box, a description above the table, a final subtotal, tax and total info box, page numbers, and configurable field labels and sublabels. The items table is configurable in its columns, with item description, breakdown, quantity, unit, price per unit, tax, and the item's total amount fields. Images are supported for a logotype scaled to fit 50px of height, a background, a stamp and signature, and a QR code. A configurable font file and a note round out the list. In other words, you place named elements and the library decides where they go. You do not get to move them.

Running it as a service through the Docker image

The repository ships a Dockerfile, and its header comments give the full sequence for building and running it. The build step tags the image locally as printer:

$ sudo docker build -t printer .

The run step publishes port 9393 on the host and runs the image detached:

$ sudo docker run -d -p 9393:9393 -t printer

The image itself is based on alpine:3.13 with build-base, bash, ruby, ruby-etc, and ruby-dev installed, and it installs the two gems at pinned versions, invoice_printer_fonts at 2.4.0 and invoice_printer_server at 2.4.0. The entry point runs the server binary with the -p9393 argument, which is the port the Dockerfile comment publishes. That pinning is worth noticing: the image installs 2.4.0 while the most recent tagged release is v2.5.0 from 2025-10-20, so building from the repository Dockerfile gives you an older server than the latest gem unless you change those version numbers yourself.

Working on the gem, running the test suite and regenerating examples

The contributing section tells you to make sure the tests pass before submitting a pull request, and gives the command to do it:

$ bundle && bundle exec rake test

There is also a script for regenerating the example invoices, which is what you run when you change the rendering code and want the sample PDFs in the examples directory updated:

$ ruby regenerate.rb

That second command matters more than it looks. The examples directory is the project's documentation, containing promo.rb, breakdown.rb, international_invoice.rb, czech_invoice.rb, long_invoice.rb, and complex_invoice.rb, each with a generated PDF and an A4 variant. Looking at complex_invoice_a4.pdf is the fastest way to see what the layout looks like when every field is filled in, and looking at czech_invoice_a4.pdf shows how a jurisdiction with different banking fields is handled. The repository also holds a benchmarks directory and a Rakefile, so the project treats rendering speed as something it measures.

The licence is MIT, but the fonts carry their own terms

The README states that the project is MIT licensed, with copyright 2015 to 2025 Josef Strzibny, sponsored by LakyAI. MIT permits commercial use, modification, and redistribution provided the notice is kept, which covers the library code and the server code. The detail to notice is FONTS_LICENSE.txt at the top of the repository. InvoicePrinter ships a separate fonts gem, invoice_printer_fonts, which the Dockerfile installs separately, and font files are typically licensed differently from code, sometimes with restrictions on redistribution or embedding. A project that ships fonts as a separate gem has separated them deliberately. If you embed a rendered PDF with a bundled typeface in a product you distribute, read that file before you ship, because the licence of the font travels into the output document.

Where the tool stops: templates, arithmetic, and non Latin scripts

There are three places where InvoicePrinter is the wrong choice, and they follow from its philosophy rather than from missing features. The first is branding. There is no styling, so a company logo on the invoice means the logotype image option, and a coloured header means the background image option. The second is money. The no calculation and no money formatting rule means tax rules, rounding, and currency display are your code's problem, and for a business with several jurisdictions that is the bulk of the work. The third is script coverage. The examples directory includes a czech_invoice example, which tells you non Latin output has been exercised, but the feature list says nothing about a wider set of scripts, so a Japanese or Arabic invoice is not something the documentation claims to handle. Also worth noting: the README does not document any authentication on the server mode, so if you expose it beyond a trusted network you would need to put your own layer in front of it.

A solo maintained project with a stable release rhythm

InvoicePrinter has been developed as a free and MIT licensed library for several years, and the release list reflects a project that ships on a predictable cycle rather than sporadically. The versions are v2.5.0 from 2025-10-20, v2.4.0 from 2024-10-13, and v2.3.0 from 2023-02-11, so the recent history is one release a year with the newest one under a year old. The last push to the repository was on 2026-05-06, which places the most recent code change some months after the v2.5.0 tag. The repository layout is that of a mature gem: a Rakefile, a Gemfile, an assets directory with the logo, a test directory, a docs directory with separate installation, library, server, and command line pages, and an .github directory. The documentation is split into four files by usage mode, which is the right shape for a tool that offers four ways in. The support note asks for sponsorship through the author's book or Rails starter kit rather than offering a support contract, so the cost of this dependency is that you own it.

Editorial conclusion

Adopt InvoicePrinter when your application already holds the invoice data and needs a printable PDF out of it without building a layout engine, and when you are willing to own the totals and the number formatting yourself. It does not fit a business that wants branded templates, currency handling, or tax computation built in, because the README lists no styling and no calculation among the features. Before you deploy it, decide which fields your jurisdiction requires, since the feature list has no line for tax rules, and pin the gem version you ship, because the container image in the repository installs version 2.4.0 while the latest release is v2.5.0.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. strzibny/invoice_printer on GitHub