I have regularly described the advantages of working with LilyPond and version control on this blog (for example in an ironic piece on things one would “miss” most with version control), but this has always been from the perspective of not having to use tools like Finale or MS Word. Now I have been hit by such a traditional workflow and feel the urge to comment on it from that perspective …
Recently I had to update a paper presentation for the printed publication, and for that purpose I was given a document with editorial guidelines. Of course I wasn’t surprised that a Word document was expected, but some of the other regulations struck me as particularly odd. Why on earth should I use a specific font family and size for body text and another specific size for footnotes? The Word document won’t be printed directly, so my font settings most surely won’t end up in the final PDF anyway because they are superseded by some style definition in some professional DTP program. Well, I could of course simply ignore that as it doesn’t actually interfere with my work. But it is such a typical symptom of academics not having properly reflected on their tools that I can’t help but make that comment.
Of course there are many reasonable rules, for example about abbreviations, but I must say when guidelines ask me to use italics for note names and super/subscript (without italics) for octave indications I feel almost personally insulted. Wow! All the authors of this compiled volume are expected to keep their formatting consistent, without even resorting to style sheets. I really wouldn’t want to be the typesetting person having to sort out that mess. What if I wanted to discern between different types of highlighting and give them differentiated appearance, for example by printing author names in small caps and note names in a semibold font variant? And what about consistently applying or not applying full and half spaces around hyphens, or rather around hyphens, en-dashes or em-dashes (hm, who is going to sort this out, given that many authors don’t know the difference and simply let their word processor do the job)?
But guess what? When I complained and suggested to at least provide a Word template with all the style sheets prepared the reply I got was one of unashamed perplexity – they didn’t really understand what I was talking about. I would like to stress that I do not mean this personally (in case someone realizes I’m talking about them …), but this was a moment that got me thinking: If I have to “professionally” discuss these matters on such a basic level how could I ever hope to get musicologists to embrace the world of text based music editing?
Well, I forced myself to stay calm and write the essay in LibreOffice (although I plead guilty to using stylesheets anyway). Just as expected, writing without being able to properly manage the document with Git feels really awkward. Being able to quickly switch “sessions” to work on another part or just to draft around without spoiling the previous state has become a second nature to me, and I really missed that. On the other hand I have to admit that being able to retrace one’s steps or selectively undoing arbitrary edits is something one rarely needs in practice. But knowing it would be possible really makes a difference and isn’t just a fancy or even nerdy idea. Think of the airbags built into your car: you will rarely if ever actually “use” them, but you wouldn’t want to drive without anymore once you have got accustomed to this level of safety. But eventually I completed the text and submitted the Word document, giving things out of hand and letting “them” deal with the crappy stuff. Unfortunately things weren’t over yet.
After having submitted my paper I learned about another paper going into the proceedings that I would like to cross-reference. So I asked the editor if I could update my paper and he said yes, there’s still time for that. But now I’m somewhat at a loss because I ended up in exactly the situation I’ve always made fun of. What if I simply send an updated document? Oops, I can’t tell if the editor has already modified my initial submission – in that case he’d have to manually identify the changes and apply them to his copy. And maybe he’d even have to adjust my updates if they should conflict with any changes he has already made. Ah, word processors have this “trace changes” option (or whatever it’s called in English programs), shouldn’t this solve the issue? Hm, partially: I have to make sure that I only apply these changes in this session so the editor has a chance to identify them properly. Then he still has to apply them manually, so this approach still includes a pretty high risk of errors happening. OK, maybe I should simply describe the intended changes in an email? Oh my, this requires me to actually keep track of the changes myself so I can later refer to the “original” state in my message. Probably I’ll have to look into that original document state, maybe from the “sent” box of my email client? And all these options don’t take into account that when the document will eventually be considered final the editor will be sitting on a pile of copies and has to be particularly careful which version to pass on to the typesetter …
Oh my, life as an author is just so much infinitely easier when your documents can healthily evolve under version control and when you can discuss and apply later edits through branches and pull requests, pointing others to exactly the changes you have applied. Of course the comparison is as lame as any comparison but to me having to develop a text with Word feels like being booked for a piano recital, showing up in the venue and instead of a Steinway D finding this on stage:
In about a month I will have to submit yet another Word document for proceedings of another conference. I realize that I won’t change the world – at least not immediately – and this awkward request will come again. But I’m not exactly looking forward to repeating the experience of being restricted to Word, so I think I will definitely take the plunge and find a proper solution this time. Pandoc will allow me to write the text in its extended Markdown syntax and just export to Word when I’m ready to submit. Until then I have all the benefits of plain text, version control above all, but also the option of editing the document through the web interface and all the other advantages of semantic markup. Maybe I can even convince the (next) editor to stick to the Markdown representation for longer so we can do the review in Gitlab and only convert the Markdown to Word for the typesetter? Oh, wait: Pandoc should be able to export the Markdown to something the typesetter can directly import into InDesign, which would allow us (well, me) to completely avoid the intermediate step of a Word document.
Wouter Soudan makes a strong point about this in his post From Word to Markdown to InDesign. His workflow is actually the other way round as it is looked at from the typesetter’s perspective: he uses Markdown as an intermediate state to clean up the potentially messy Word documents submitted by authors and to create a smooth pipeline to get things into InDesign – or optionally LaTeX.
I have only scratched the surface so far, preparing the script and slides for a (yet another) presentation together with Jan-Peter Voigt. He has set up a toolchain using Pandoc to convert our Markdown content files to PDF piped through LaTeX. I will definitely investigate this path further as it feels really good and is efficient, and maybe this can be expanded to a smooth environment for authoring texts including music examples. Stay tuned for any further reports …