Ask HN: What software should I use to write a textbook?

Looks like you should use pandoc (or asciidoc) from within your favorite text editor (e.g Visual Studio Code, Atom, ...) Using raw LaTeX is wasted effort IMHO, only commit to it, if you really need it. If you want to sell later as E-Book, i recommended to get the technical details right now. This might give you an edge over authors who are only able to deliver a converted pdf.

I wrote a perl book using pod (the perl doc format). The process was baroque: pod to latex,latex to rtf. Which then gave me an msword interchange format - important for the publisher.

I also wrote a PhD thesis. I started with various msword compatible formats (for process reasons). I curated the documents into markdown and was hoping to use markdown/citeproc to produce a thesis via either msword or latex. However that was going to be a pain in the bum, so I finished it up with latex/hyperref/bibtex.

So, tl;dr I think if your book is not citation or maths heavy and you are in control of the process I would recommend markdown to latex via pandoc. If it’s citation heavy,then I’d probably recommend cutting out the pandoc middleman and going straight to latex/bibtex. If it’s maths heavy then markdown to latex might work. If it’s someone else’s process, I recommend jury rigging something that will get them an MVP.

Vim

I'll simply quote a thread by William Adams on the context mailing list (copied from here http://wiki.contextgarden.net/Comparison_between_ConTeXt_and..., the link to the mailing list does not work)

With a graphical tool, one is limited to the automation which the developers are willing to build into the tool and sentenced to handling manually everything else, every time that there's a change, e.g., if you have a keyword block on your opening article pages aligned against the outside gutter and the layout program can't place it automatically and contextually, then every time the article changes from opening to a left to a right or vice-versa one has to make that change manually.

I wrote up a longer comparison once upon a time --- Scribus isn't that much different from InDesign and Quark, so the criticism holds:

While I'm no TeX wizard, I prefer it because it allows one to off-load some of the tedium and repetitiveness to the computer, as opposed to repeatedly solving variations of the same problems by hand time after time after time.

So,

* using Quark is like being chained to a an oar which is covered w/ splinters and mostly broken at the other end and which will randomly break due to being poorly carved (Quark has crashed on me 183 times this year) leaving one adrift or run aground, or sometimes returning the vessel to its starting point (a few of those crashes have resulted in unrecoverable document corruption --- my autobackup folder may contain 2 or 3 GBs of files for a given iteration of a particular project each month) --- the oar can be smoothed somewhat and reinforced (by purchasing or finding XTensions, using XTags &c.) and periodically one is required to purchase a new oar (sometimes just after the previous one has been customized adequately). For some tasks, one can impress any graphic designer as a galley slave to ease the effort for others, but while charts are available, there are no automagic navigation options and every journey must be manually piloted.

* using InDesign is pretty much the same except the oar is smoother and stronger (it's crashed 29 times on me thus far this year), there aren't as many customization options and it's not quite as easy to find a candidate for impressment (though soon it'll be as easy as for Quark). Charts are available, but again, piloting is strictly manual.

* using Plain TeX one has to craft the vessel's oar oneself (as well as the rest of the vessel unless one is typesetting a clone of The TeXbook), but it's as sturdy and as nice a one as one's skills allow and can even be an engine which moves the vessel in and of itself --- it can be difficult or impossible to find people suitable to help w/ either carving the oar or using it though, but once a given journey is worked out, the oar becomes magical and rows for itself except for when one runs into an unplanned for obstacle (the navigation charts are old ones and not often up-dated, with a lot of “terra incognita”), allowing one an auto-pilot option for certain journeys, dependent upon one's skill. using ePlain, an oar is provided, can be customized, and can be enchanted and the charts are okay, but have a lot of “terra incognita” on them.

* using LaTeX, an oar is provided and there're lots of nifty customizations and improvements already available, and one can impress additional oars from CTAN, however on a semi-random basis, adding one oar will break other oars, sometimes leaving one adrift or run aground. One can enchant a set of oars to accomplish a given journey, easing the piloting requirement, and the navigation charts are decent and obstacles are fairly well-known.

* using ConTeXt, a very nice oar is provided, which has lots of customization options, but the navigational charts aren't easily read by a traditionally trained navigator at first, although they are fairly compleat and most journey can be carefully worked out, but once one is, it is quite automatic and there's a good auto-pilot option.

As a sidenote that "someone" is Andrew Glassner [0] :) - i.e. the editor of the venerable Graphics Gems series and much else. The books you refer to are here

https://www.glassner.com/portfolio/deep-learning-from-basics...

As another examples Google's Filament PBR renderer has beautiful documentation written in Markdeep as well: https://google.github.io/filament/Filament.md.html

[0]: https://en.m.wikipedia.org/wiki/Andrew_Glassner