Write a Book with Markdown
pianomanfrazier.com
pianomanfrazier.com
I know it's of little use since you usually install all dependencies on a dev machine and simply run fast scripts locally, but Gitlab CI is really a nice tool to use, and you've got some free build minutes you can use on the Saas instance. Then you can make edits on any machine using the Web IDE, and easily share the result hosed on Gitlab pages.
- Markdown mode in terminal emacs - Pandoc export with .emacs script or shell script for books with chapters in separate files - Zotero with BibLaTex to manage .bib file - Git for version control
This has worked beautifully for three trade books and one academic one. The only sad part is when we shift from writing and revising to copyediting, when I have to edit the press's track changes in LibreOffice.
Haskell had a significant "win" for me there: real world code I depend on, written in an FP language.
I do sometimes wish I could make tables which were less "TeX-y" -which is running a bit counter to the style/vibe but I do miss more boring tables a la TBL/Troff
I currently live in org mode in emacs and use various org mode exports to get things which I like better through pandoc, but pandoc direct from org mode isn't bad.
I haven't yet had to do indexing, or bib. indexing is really hard. Well.. there's simple but time consuming (multi pass) and there's hard (what you index) and there's re-indexing to suit the pagination of the form you render.
I did Kindle direct print for a real author from word inputs and it was a journey. When you find yourself hunting for guides to GSM weights of paper to calculate your thickness to position the spine to define the ISBN region...
Cut marks are another bugbear. It should be easier to just tell something (pdf stage?) to insert/intrude cross hairs at the cutmark points you want.
- Use tools sufficient to your needs.
- Don't be a slave to your tools or any given toolchain.
For reasonably simple books, Markdown is sufficient. If all you're dealing with is text, paragraphs, chapters (and perhaps sub-chapter and super-chapter sections), and perhaps a few additional features: italicised and bold text, lists, and simple tables, you'll be more than fine with Markdown. I've typeset numerous books (my own work, from plain text, typed in) in this manner. The default output is fairly generic, but it's more than adequate for simple use.
Much of the styling can be enhanced without abandoning Markdown simply with a more-advanced stylesheet.
And if you do find that you're exceeding the (surprisingly adequate) capabilities of Markdown, or another lightweight markup language, then it's also straightforward to migrate to LaTeX or DocBook and incrementally augment the work from there.
As with the advice to buy cheap tools and upgrade the ones that break, starting with a sufficiently reasonable base is often a good way to get a project rolling.
Keep in mind that people wrote books with paper and typewriters, or quill and ink, long before advanced typesetting tools were available. The fact that we can now typeset-as-we-write doesn't mean we must.
My last two publishers required Word which was a nightmare. I maintain some docs in markdown which is OK but pretty limited when it comes to the advanced stuff.
Building a markup language is really easy. That's why we have so many and multiple independent implementations of markdown. The problem is that last mile to get production and mostly printing right. That's super hard and even asciidoctor doesn't get it perfectly.
These Manning does use asciidoc for writing, it's great for that. But when you need to create a book they move it to docbook and then typeset using the traditional typesetting programs. Despite all the work it's 95% of the way for the sublime book experience. I'd say every other alternative is 90% of the way at best.
To get a sense of what you need to do to create a professional book without that typesetting work check out this post https://medium.com/sketch-app-sources/using-sketch-and-ascii...