The code and open-source tools I used to produce a science fiction anthology

I’m not a professional publisher. I have a full-time job and two small kids, so all of this work happened after my kids went to sleep. I had to use my time judiciously, which meant creating an efficient process. Fortunately I’m a programmer, and it turns out that programming skills translate surprisingly well to book publishing. This post is about how I built a complete publishing pipeline using Python, YAML files, and LaTeX — and why you might want to do something similar if you’re considering publishing a book. I know that by writing this I’ll have my choices questioned by professional designers, but hopefully the software concepts will be helpful. My initial thought: can I really do ALL of this? When I started this project, I had some worries. Professional publishers have entire departments of specialists. How could I possibly handle all of that myself? The answer turned out to be: build tools that automate the repetitive parts, and use simple file formats that make everything transparent and debuggable. Step 1: Tracking stories with plain text files The first challenge was tracking hundreds of candidate stories from different magazines. I read 391 stories published in 2024 before selecting the final 16. That’s a lot of stories to keep organized. I could have used a spreadsheet, but I went with plain YAML files instead. Here’s why this worked well for me: The structure looks like this: Each story file is pure YAML containing the full story text plus metadata: Not all stories have public URLs available, but that’s OK because all of the fields are optional. The central story-progress.yaml tracks editorial state: Step 2: A simple command-line tool I built a small Python CLI tool (se.py) to help me navigate all this data. Since I do all this work at night after my kids go to sleep, I wanted something fast that mirrored a lot of the other work I do on the command line. The tool is simple: The compile command ended up being really useful — it gave me instant feedback on anthology size and composition: This was really helpful during the selection process. I could quickly check how far along I was toward my ~120k word goal, and make sure I hadn’t accidentally included multiple stories by the same author. Step 3: Typesetting the print book This part surprised me the most. I initially thought I’d have to learn Adobe InDesign or pay someone to do the typesetting. But I decided to use LaTeX instead, since I had some previous experience with it (another publishing friend sent me some of his example files, and I had some academic experience). The process worked out better than expected. I used XeLaTeX with the memoir document class. Here’s what I liked about this approach: The main parts of the master file for the book are really simple: The microtype package does a lot of subtle work with character spacing and line breaking that makes the text look professionally typeset. I wanted story titles in bold sans-serif with author names underneath in a lighter gray. Here’s how I set that up: This redefines the chapter command to take two arguments, the title and byline, and sets up both the chapter formatting, TOC formatting, and makes sure that the title and byline are printed in the headers on alternating pages. Now every story file just says: Most authors send me stories as HTML, PDF, or word, so I needed a way to convert them to LaTeX. I wrote a simple Python script to do this, which saved me a huge amount of manual formatting work. Step 4: Creating the ebook Print was one thing, but I also needed an ebook. This turned out to be easier than I expected because I could reuse all the LaTeX source I’d already created. I used Pandoc to convert from LaTeX to EPUB: Pandoc’s default table of contents only showed story titles. But I wanted author names too, like you see in print anthologies. EPUBs are just zipped collections of XHTML files, so I wrote a small post-processing script: The script unzips the EPUB, finds the navigation file, adds author bylines, and rezips everything. Now the ebook table of contents matches the print version. What I learned The whole process took longer than I expected — many months of night work. The simple software I wrote really made it a feasible one-person project though, and motivates me to go through the whole process again next year. Staying organized is crucial. When hundreds of stories are involved, it’s easy to forget details, so using se.py to save metadata in the moment that could be sliced and diced later was so important. Reproducible builds were a lifesaver. I made changes to the book layout right up until the week before publication. Because I could rebuild the entire book in seconds, and everything was backed up in git, I could experiment freely without worrying about breaking things. Simple file formats made me comfortable. When something went wrong, I could always open a YAML file or look at the LaTeX source and understand what was happening. I never hit a point where the tools were a black box. I didn’t need to understand everything up front. I learned LaTeX details as I went (arguably I still don’t really understand LaTeX). Same with Pandoc. I got something basic working first, then incrementally improved it. Can you do this too? If you’re thinking about publishing a book — whether it’s an anthology, a novel, or a collection of technical writing — I think this approach is worth considering. There’s something motivating about having a detailed understanding of every step in the production process. If you have questions feel free to reach out, I love talking about this hobby! You can email me at [email protected].