3 ms·

I've wondered about this many times -- your conversion is a one-way street, right? Let's say you have your source material in MD stored in Git, convert it to d

I've wondered about this many times -- your conversion is a one-way street, right? Let's say you have your source material in MD stored in Git, convert it to docx and send it to your client. They use Word to make annotations and revisions and send it back to you. Now what? How do you get this back into MD and your Git repo? Of course you can do this by hand, but that's terrible work. It certainly is worse than staying in the Word ecosystem and flying with it. Not that I'm advocating this, but I don't see how "backporting" their proposed changes into some local Git branch in MD scales. So, I'm curious about your solution to this.

deleted 5y ago
[deleted]
leephillips 5y ago
I’m in the same boat, often, and there is no solution. I do the original writing with Pandoc/Markdown, but I’ve resigned myself to working in the client’s format for subsequent revisions. If a revision requires a lot of new content, I write that again in Pandoc/Markdown and paste in the converted result.
marcosdumay 5y ago
Oh, the Word "mark changes, annotate and pass away" model of change control doesn't work when everybody is using Word either. It's basically deeply flawed, and once somebody decides to go through that road, your best bet is to read the annotations and redo them manually on the original document. That works about as well if your original is in Word or any other format.
Veen 5y ago
Yes, it's a one-way street. Edits and revisions have to be done in Word, unfortunately. What makes it worse is that most people don't know how to use Word properly either, so you end up with documents with multiple fonts, text in a dozen different colors, half the suggeted edits as comments/annotations and half as text written into the document, random highlights with no context, and so on. Complete pain in the arse. But at least the part I control is plain text, version-controlled, and easily scripted.
- cxr 5y ago
  It's too often overlooked that HTML is an acceptable* office file format. Suppose that rather than a docx, you handed them what we might call a "doch": a self-contained (no external resources) .html file that includes more or less what you'd get by doing "Save as HTML" in a traditional office suite. This would work well enough on their end, no? They should still be able to double click to open it. The difference being that since the W3C/WHATWG specs involve a whole programming system supported by the browser, then you could also script a lightweight sidebar that they could use to add their annotations. The positive would be that, since you control the implementation and therefore the experience, you could (a) take the necessary steps to ensure that the alterations they're making follow a consistent format, and (b) can be more easily ingested by your tooling in a way that's compatible with your preferred workflow. * close enough to cover the 80% of features where it matters (e.g. for media not meant for print)

deleted 5y ago

[deleted]

leephillips 5y ago

I’m in the same boat, often, and there is no solution. I do the original writing with Pandoc/Markdown, but I’ve resigned myself to working in the client’s format for subsequent revisions. If a revision requires a lot of new content, I write that again in Pandoc/Markdown and paste in the converted result.

marcosdumay 5y ago

Oh, the Word "mark changes, annotate and pass away" model of change control doesn't work when everybody is using Word either. It's basically deeply flawed, and once somebody decides to go through that road, your best bet is to read the annotations and redo them manually on the original document. That works about as well if your original is in Word or any other format.

Veen 5y ago

Yes, it's a one-way street. Edits and revisions have to be done in Word, unfortunately. What makes it worse is that most people don't know how to use Word properly either, so you end up with documents with multiple fonts, text in a dozen different colors, half the suggeted edits as comments/annotations and half as text written into the document, random highlights with no context, and so on. Complete pain in the arse. But at least the part I control is plain text, version-controlled, and easily scripted.

cxr 5y ago
It's too often overlooked that HTML is an acceptable* office file format. Suppose that rather than a docx, you handed them what we might call a "doch": a self-contained (no external resources) .html file that includes more or less what you'd get by doing "Save as HTML" in a traditional office suite. This would work well enough on their end, no? They should still be able to double click to open it. The difference being that since the W3C/WHATWG specs involve a whole programming system supported by the browser, then you could also script a lightweight sidebar that they could use to add their annotations. The positive would be that, since you control the implementation and therefore the experience, you could (a) take the necessary steps to ensure that the alterations they're making follow a consistent format, and (b) can be more easily ingested by your tooling in a way that's compatible with your preferred workflow. * close enough to cover the 80% of features where it matters (e.g. for media not meant for print)