Back in 2020 I gave a pretty definitive statement of my position on physical books. When brian d foy interviewed me for perl.com, I said, among other things: “I do like a real book. But they take up too much space, so I’ve pretty much completely stopped buying them over the last five years.”
That interview was done to promote the sixth Perl School book, The Best of Perl Hacks, so by that point I’d already been running an ebook-only publishing imprint for three years and was apparently still very comfortable with that decision.
And I stand by the sentiment. I love ebooks. I can carry my entire library in my pocket. Font size, brightness, instant delivery — what’s not to like? For years I’d been mildly irritated by publishers who promised me an “ebook” and delivered a PDF that was made to be read at a fixed size and fell apart on anything smaller than a large tablet. A proper ebook format reflows. It adapts. It goes where you go.
It seemed obvious, then, that Perl School should be ebook-only. No printing, no warehousing, no minimum print runs, no logistics. We started in 2017 with Perl Taster and have published nine titles since then — everything from a Selenium testing guide to a book on Cucumber to a collection of my best Perl Hacks posts. All ebooks. All on Amazon and/or LeanPub.
It turns out I am not representative of my audience. This is, of course, an important marketing lesson!
This should probably not have come as a surprise. Assuming you are a typical user is the most dangerous thing you can do as a technologist, and I’ve been in this industry long enough to know that. Yet somehow I still managed to assume that Perl developers were like me: screen-first, happiest with an ebook, not missing physical books at all.
The emails asking whether Perl School books were available in print suggested otherwise. And when Mohammad Sajid Anwar finished Design Patterns in Modern Perl, the demand for a physical edition was too consistent to ignore. Mohammad is a prolific Perl contributor (you may know him from his work on the Weekly Challenge or Perl Weekly), and his readers, it turns out, wanted something they could put on a shelf.
Amazon’s Kindle Direct Publishing (KDP) is the system you use to push ebooks into the Amazon machine. But you can also use it to publish paperbacks. And the barrier to entry is genuinely low. You supply a properly-formatted PDF for the interior, a cover image, choose your trim size and paper type, set a price, and wait for a proof copy to arrive in the post. No printing contracts, no warehousing, no minimum print runs. Print-on-demand means each copy is produced when someone orders it. KDP handles fulfilment, returns, and royalty payments. As a publisher, you just need to get the files right.
That said, “low barrier” doesn’t mean “no work.”
Our existing build pipeline already took Markdown source through pandoc to produce both a PDF and an EPUB. The PDF looked good on screen and worked fine for the A4 digital edition we’d been producing. But KDP paperbacks have their own specific requirements: the correct page dimensions for your chosen trim size (we went with 7″×10″, roughly the size of a standard technical textbook), margins that meet their minimum gutter requirements, and bleed on the cover image.
The gutter requirement caught me out. KDP scales its minimum gutter—the margin on the binding edge—with the page count of the book, because thicker books flex more when opened and text can disappear into the spine. For a 294-page book, the minimum gutter is half an inch. That’s more than we’d originally set, so the CSS needed adjusting. KDP’s print-readiness checker caught this when we uploaded the first attempt.
We also discovered that some code lines in the benchmark output sections were overflowing the right margin. In an ebook, this is invisible because text reflows to fit the screen. In print, it is not invisible at all—the text simply runs off the edge of the page. The fix was a small Perl script that identifies those specific lines and wraps them for the print build only, leaving the ebook output completely untouched. The same Markdown source produces both formats; the script runs only when building the KDP PDF.
The cover was its own adventure. The ebook cover image had been designed at 1600×2400 pixels, which works well for an ebook. But KDP’s front cover panel for a 7″×10″ book with bleed requires a different size and aspect ratio entirely. I had to work out the exact pixel dimensions—accounting for the trim size, the 0.125″ bleed allowance on all outer edges, and the spine width (which KDP calculates from the page count and paper type)—and then extend the original background pattern to fill the larger canvas. That’s the kind of fiddly arithmetic that’s easy to get slightly wrong, and I did get it slightly wrong the first time.
I also discovered, while working on the new cover, that the ebook cover had “Perl” duplicated in the title. The intended layout has “Design Patterns in Modern” on the first line, then a large “Perl” wordmark below it—so the full title reads as “Design Patterns in Modern Perl.” But the first line had originally been set to “Design Patterns in Modern Perl,” meaning the cover actually read “Design Patterns in Modern Perl Perl.” This had been the case for six months. The corrected ebook cover is in progress.
For all of this, I had help from Claude Cowork, Anthropic’s desktop AI tool, which I’d been using more and more for exactly this kind of technical publishing work. It helped write the CSS changes for the print layout, worked through the cover dimension calculations with me, rendered specific pages of the generated PDF to check for overflows and margin problems, and spotted the “Perl Perl” duplication that I had entirely failed to notice.
That last one stings a bit. But in fairness, catching subtle errors in things you’ve looked at many times is exactly the kind of task where a second pair of eyes—artificial or otherwise—earns its keep. It’s not the same as having a professional production editor, but for a small independent publisher with no budget for one, it covered a surprising amount of ground.
Design Patterns in Modern Perl is now available as a paperback. The page links to your local Amazon store. It’s priced at £20 (or local equivalent), which produces a per-copy royalty that compares rather favourably with what the traditional publishers were paying me back in the day—though we’ll need to actually sell some copies first before that becomes relevant.
This is an experiment. If the book sells—and I’m deliberately not defining “sells well,” because I don’t want to commit to a number I’ll later have to explain—then more Perl School titles will follow the same route to print. Mohammad has written a genuinely useful book. If you’re working with Perl and want to think more carefully about how you structure your code, it’s worth your time. And if you buy a copy, you’ll be helping to settle the question of whether Perl developers really do want physical books, or whether I was right all along.
I suspect I wasn’t.
