This is an impressive and detailed writeup, so thank you for sharing not only your process but the thinking and reasoning behind it. I especially appreciate the list of tools [0] and book design resources [1]. I hope my comments/observations don't seem overly harsh:
First, a question: is there a link to example source code, e.g. a folder of Markdown+.text files, the bash scripts, and the resulting PDF?
Speaking as someone who has put a decent amount of time in looking at plain-text-publishing systems (such as Leanpub's Markdown system, Hadley Wickham's RMarkdown books [2] and u/munificent's custom build script for "Crafting Interpreters" [3]), I have an idea of my current pain points, and I want to see via-example of whether your process deals with them, before I get into your technical details.
Without such an example (and if I'm being honest, even with great examples), I can't bring myself to do more than skim your material, because the steps seem so complicated, and I can't easily discern how they improve how I currently use Pandoc to do the Markdown->PDF process. For example, I'm currently trying to use Python's Sphinx [4] – which, besides being great at creating an online reference site, can also output s compiled file that I can pass into pandoc with a pre-defined Makefile. So all the steps (again, just based on my skimming) you detail in your "Part 1: Build Script", which include writing the argument parser in Bash, seem orthogonal to the plaintext-to-PDF process?
> which include writing the argument parser in Bash, seem orthogonal to the plaintext-to-PDF process?
You are on-point. For people unfamiliar with bash, the explanatory steps provide an idea of what the scripts do, the rationale for crafting them that way, and how to modify them.
Feel free to skip over the bash-bits and download all the code. A few of the posts have a download section that you can jump to (#download) to grab a copy of the completed scripts in a zip file. Once you've extracted the scripts, you can start using them and follow along with the remainder of the steps that interest you.
The scripts form part of a continuous development process. The scripts regenerate the PDF whenever a source file changes.
First, a question: is there a link to example source code, e.g. a folder of Markdown+.text files, the bash scripts, and the resulting PDF?
Speaking as someone who has put a decent amount of time in looking at plain-text-publishing systems (such as Leanpub's Markdown system, Hadley Wickham's RMarkdown books [2] and u/munificent's custom build script for "Crafting Interpreters" [3]), I have an idea of my current pain points, and I want to see via-example of whether your process deals with them, before I get into your technical details.
Without such an example (and if I'm being honest, even with great examples), I can't bring myself to do more than skim your material, because the steps seem so complicated, and I can't easily discern how they improve how I currently use Pandoc to do the Markdown->PDF process. For example, I'm currently trying to use Python's Sphinx [4] – which, besides being great at creating an online reference site, can also output s compiled file that I can pass into pandoc with a pre-defined Makefile. So all the steps (again, just based on my skimming) you detail in your "Part 1: Build Script", which include writing the argument parser in Bash, seem orthogonal to the plaintext-to-PDF process?
[0] https://dave.autonoma.ca/blog/2019/05/29/typesetting-markdow...
[1] https://dave.autonoma.ca/blog/2020/04/11/interior-book-desig...
[2] https://github.com/hadley/r4ds
[3] https://news.ycombinator.com/item?id=22788738
[4] https://pedrokroger.net/using-sphinx-write-technical-books/