The place command does not autoupdate. At least not in the most recent version.

Text is either embedded, in which case it's baked in, or linked, in which case you have to manually tell ID to update the link to reload the text.

But InDesign's EPUB output is horrifically terrible, especially if you're trying to use custom fonts/graphics for page headings. (Basically - no.)

And the CSS is... really not great.

The best fiction off-the-shelf option for EPUB gen is Vellum. It's a one-off payment of around $250 and you can get an EPUB-only version, or EPUB+PDF for print. It's not very customisable, but the presets - there aren't many - all look good.

For anything more sophisticated, options are limited. I spent far too long creating a non-fiction EPUB in ID a couple of years ago. I got there in the end but it was an extremely painful process and I ended up automating a lot of the workflow in JSX.

For fiction I created my own MD -> EPUB pipeline with a custom MD -> HTML parser for custom markup not handled by pure MD. Then a custom EPUB builder which does all the wrapping and general EPUB bureaucracy based on my own CSS.

Python has libraries for Pandoc, native DOCX, and MD (up to a point) so the basics were all there. The rest was glue.

It was a moderately-sized hobby project - would probably go much faster with AI now.

> Overall, as a technical writeup I enjoyed the article; however, I would caution that the author seems to approach publishing from an amateur perspective.

I also worked at a publishing company (for ~6 years) in the early 2000s. While you are right that the pros have some tricks to make the process easier, the fact remains that the process is not easy at all. Unlike in academic publishing, where nothing stands between the author and the reader, at a commercial publishing company (at least one of the majors), there are legions of people working behind the scenes. Editors communicate with authors; editorial assistants help the editors with fact-checking, drafts, basic organization and comprehensibility; copyeditors get all pedantic about formatting and word choice (sometimes resulting in arguments with authors that the editors need to smooth over); production departments that make the books look pretty, contain images whose copyrights are cleared and that can be legibly printed within a reasonable budget; graphic designers who develop house styles or even a custom style for a book and even original cover art; lawyers who negotiate copyrights for excerpts, images, and other ancillary materials; and on and on.

I know all this because I worked on a custom content management system for this company and in so doing I discovered that the process was incredibly complex. One of the major pet peeves of everybody involved was when an author thought they were doing anybody a favor by trying format things in Microsoft Word. Most of that information was thrown away and the real layout was done by people who thought in terms of widows, orphans, kerning, and leading (and so on). Once you know what all the people in a top publishing company do, the difference between an amateur publication and a professional one becomes immediately apparent. So I don't fault the author for getting a bit technical. The SE approach sounds like an epic attempt to make a complicated subject at least somewhat approachable.

> For example, "Making the slightest change became a chore. [1.] Update the 'master' DOCX. [2.] Update the InDesign file ..." --the appropriate way to use an external document as master in InDesign is to use the Place command, which autoupdates text changes as they are made in Word.

It does not auto-update. Even if it did, you wouldn't necessarily want it to auto-update, because it's very hard to tell if changing one sentence in your manuscript has borked the layout of dozens of pages. Once you have rules set up around widow and orphan control, it's very easy for even tiny text changes to have large downstream layout effects.

Also, frankly, InDesign is kind of flaky and will sometimes change layout or make other visual changes in response to apparently nothing at all. I ran into a bug where it would just silently drop underlines on some elements and jiggling them a bit would bring them back.

For my two books, I ended up writing a script that would generate a visual diff of the entire book from the PDF export of the InDesign files so that I could tell for certain if InDesign had gotten itself confused. InDesign can produce beautiful output, but like a lot of Adobe software, it's temperamental and opaque.

For my part, my approach was to set up a Word .docx file with styles, which would import into Adobe InDesign, mapping style-to-style, and if need be, pre-process w/ one or more AppleScripts and page as normal, then when it was time to return the edited manuscript to the author(s), select all the text and remove over-rides and export the text as a .rtf from InDesign, open that in Microsoft Word and re-save as a .docx.

The annoyances of using "soft wraps" with various kinds of tools is one of the maddening irritations of our software landscape. Inserting non-semantic newlines in content just to make things fit the screen is insane.

From the about page:

  D. J. Speckhals is the author of the “Witnesses of the Light” historical fiction trilogy, which transports readers to fifteenth-century Europe to explore the resilient faith of the Waldensians.

> but the text color is usually set slightly off black (why!!??)

This can be cause by colour management. If the black is defined in terms of RGB and then converted to CMYK as part of the pre-press workflow, you'll typically have a mix of all four inks, and not necessarily 100% K - it depends on the colour profiles. For a black-only print job the C, M and Y channels will then be discarded, leaving a maybe-not-pure black.

This is why PDF/X exists

> why is the text color set slightly off black

Because pure black causes eye strain. Dark gray on white is superior for long reading sessions when your paper is white. The contrast really hurts after a while if you do pure black on pure white. This is a known phenomenon.

In fact, there's experimental evidence (https://www.nature.com/articles/s41598-018-28904-x) that this high contrast plays a hand in the onset of myopia, which in extreme forms is correlated with glaucoma and other vision disorders.

I hope the negative reactions here are to the truncated title (HN drops the “How” from titles). The author doesn’t seem to be claiming anything revolutionary, just describing how they created their pipeline.

Good grief.

> Please don't fulminate. Please don't sneer, including at the rest of the community.

> what CS PhD students have been doing ~forever.

Or what every researcher has been doing for literally decades (except with other versioning systems, but still typesetting without Word or Adobe).

No need for techbros to pat themselves on the back as innovators.

I typeset my novels in LaTeX and use GIT. I even just clone a base repo whenever I'm going to release another.