How to manage text for web and print simultaneously?
June 4, 2021 2:49 PM   Subscribe

I have a novel length reference document nearing completion. It's end purpose is to be used both in a web app and also in print form. What format is best to keep a source of truth for the text itself with minimal effort converting from one form to the other? Are there text managent tools for this?

The reference document is ~100,000 words, that right now live in Google docs. I'd like to move it to a single file that I can use as the source of truth for both web and print.

Here are my requirements:
  • It needs to be source control friendly so I can view line diffs in GitHub instead of just some binary blob.
  • It needs to be directly consumable in JavaScript, so my React app can just render it as components.
  • When the time comes to typeset this I'd like to be able to preserve, at a minimum, the heading hierarchy when I import.
  • I can build things like crosslinking and search on top of the web version and nice typesetting and illustrations in top of the print version, but both use the same core text.
How do I do this? I'm considering these two workflows so far, but is there a better tool I'm missing?
  1. Make it all in html > React does something like dangerouslySetInnerHTML > then I handle the print version with an extremely baroque print stylesheet. Is it even plausible to typeset with css and have it printed though?
  2. Make it in markdown > use some React markdown lib > use some tools Google suggests can import the markdown into InDesign or Affinity Publisher > typeset properly. How much formatting can I reasonably expect to maintain when I do this?
How can I bridge the gap without manually reformating twice?
posted by cirrostratus to Computers & Internet (5 answers total) 3 users marked this as a favorite
 
For option 2, In the past I've done markdown -> convert to icml with pandoc -> import to InDesign. That process is thoroughly described here (specifically this part). My styling needs were pretty straightforward - font size and margins on headers and subheaders mostly, but I found that I had all the control I needed over things.

To option 1, perhaps you've already seen this but CSS gives you a great deal of control over print layouts as well. So I'd say "yes" to "is it plausible," but personally I'd still probably choose option 2.
posted by mustardayonnaise at 3:14 PM on June 4


The old school solution to this kind of problem is LaTeX, which is certainly capable of representing, in a plain text and therefore source-code-control friendly format, anything you could conceivably want to put in a book; webby goodness can be automatically derived from it using LaTeXML.
posted by flabdablet at 3:22 PM on June 4


Once you decide on your tools, look into automating the conversion process through some sort of pipeline at Github or similar sites.
posted by lhauser at 5:08 PM on June 4


That's good advice, because if your single source of truth can be automatically translated to an intermediate format suitable for web app consumption every time you save an update to it, then it will cost you no extra time to maintain it in a format that won't send you crosseyed with angle brackets and captures everything you need for typesetting better than Markdown ever could.
posted by flabdablet at 5:23 PM on June 4


You might want to look into the domain-specific Lisp/Racket dialect called pollen, which was designed for this situation. Personally I do something similar by writing everything in org-mode and using either org-publish or Pandoc to get output files to other formats. But this only works for me because of the emacs ecosystem.
posted by overeducated_alligator at 5:32 PM on June 4


« Older Has anyone famous ever died in a commercial air...   |   Convert extreme fisheye video to equirectangular? Newer »

You are not logged in, either login or create an account to post comments