I am posting this in the MultiMarkdown section but it’s possible it belongs in a better place depending on the discussion that ensues. I have been working on a long academic (humanities) project using inline scrivener footnotes but with all text in strict MMD otherwise.
I am approaching completion (!) and am getting ready to transact with an editor who only uses MS Word / track changes. I am thinking of actually trying to get her to do track changes on a simple unconverted dump of the raw MMD into the MS Word file. I think she will be okay with *=ital, etc, but the inline footnotes will create an issue.
In any case, the footnotes are getting to the point where they need to be separated from the text for my own editing purposes. I am not happy with the default MMD compile where they are all lopped onto the end of the document (unless perhaps I am missing an option there). In a long doc, that can be way too far from the main text.
I am wondering what good practice might be here and how to move toward it – MMD formatted notes at the end of each of the 80 or so docs? In a separate doc or docs per chapter? How does converting from scrivener inline to scrivener inspector work – how does it deal with the positioning of the note (they are all at the end of sentences)? How does it impact on MMD compiling later?
Any suggestions are appreciated. Thanks very much.
In MMD, the placement of the footnote text is completely irrelevant. They can be right below the paragraph that calls them, or miles away. When the document is run through the post-processing engine, they will be converted to something that is appropriate for the format in use. For LaTeX that means footnotes (where they will be typeset properly at the bottom of the page). For HTML—well there is no way around the fact that HTML is a long stream of text, so they will be endnotes then. For ODT (in MMD3) they will become word processor compliant footnotes.
There is no practical difference with MMD. They are both treated the same. There is one small subtle difference: inspector footnotes will use a different label prefix in the MMD anchor text—so you could concievably treat them as a second note stream with a custom XSLT. If you don’t, then this is completely invisible in the end product as the internal footnote ID is not used for anything in the end product.
General advice: you might be at the point where most other Scrivener users start working in Word. If you’ve done the principle composition and are now going back and forth with an editor—trying to keep everything synced up between their notes and Scrivener might prove to be more effort than it is worth. I wouldn’t necessary say that an MMD user is in a better or worse position than an rich text user at that point. In both cases, the fundamental problems go back to you being in an outline based document generator, and their being in a single-document word processor. The two don’t communicate very well at a fundamental level. You can still use Scrivener to keep track of all the details. Basically, use Word, but periodically import the updated drafts into the Binder (not to replace the primary Draft, but just as a reference). That way you can still take advantage of all your notes and research material.
Best route out of MMD to the word processor world is ODT. You’ll need LibreOffice to open an .fodt file, and from there you can save it to .doc.
AmberV, thanks for the info. Really though what I’m asking is: my footnotes are scriv inline notes right now. Are there some good strategies for converting them into MMD automatically such that for readability they are located reasonably near the spot in the main text to which they refer?
I think if they can be situated at the end of the relevant paragraph or subsection (which is a individual document in my file), my editor will be able to markup a pseudo plain text file in word that I can then make the changes on and then copy as plain text back into scriv one subsection at a time.
I can’t bear the thought of switching to word for final formatting – I will want LaTeX.
Hmm, nothing fully automatic. Best thing I can think of would be to compile each section to plain MMD without any meta-data (use the option that keeps compile group hierarchy intact so that everything doesn’t end up with level 1 headers). Name them with a sequential number so they stay in order. That will group any relevant footnotes from that section at the bottom of each section file. After generating a big swath of these, make a blank project in Scrivener, dump them all into the Draft and compile out to Original/Plain-text to combine them into a single file. The numerical names won’t matter at that point since Original only emits text from the draft, no titles—those should already be baked into the text via MMD. You could even import this combined file back into the main project with File/Import/MultiMarkdown File.... So long as you don’t use much by way of Inspector features and Scrivener Links, that’ll get you back to where you started—but with hard-coded footnotes instead of soft footnotes.
You probably wouldn’t want to do that at the sub-section level though, and certainly not the paragraph level. I’ll see what Keith thinks about adding something like this as a compile option for plain MMD, to basically put any MMD generated footnote texts at the end of the binder level item they came from. That mightn’t be too difficult to do. We’re going to be examining the MMD system in general to get it up to speed with MMD3, so I’ve got it in the pile of things to consider at that point in time.
If you’re handy with a scripting language, that would be another option. Just compile the whole thing out in one shot, then write a script to move the footnote markers up to where you want them.
Thank you very much. I have one other question. How do inspector window footnotes get handled in terms of encoding in text files compared to inline? For example if I were to export my files w inline ey become {{…}} – what happens with inspector notes and is this useful to my situation?
Best,
Rebecca
The {{…}} notation is used most effectively in the File/Sync/with External Folder command. There, it will convey inline footnotes to plain-text and back again, and so is a useful way to handle footnotes in a sync workflow.
That’s an option, if your editor doesn’t mind working in small pieces. That’s the main problem with using this tool for collaboration; it’s really tune to be of more use to the author since it creates a file for each section in the binder.
Linked footnotes have no round-trip mechanism like this. I don’t recommend people use them if they are heavily syncing to plain-text as it is too easy to lose them.
I now know enough about MMD to ask a stupid question or two.
There are MMD footnotes where there footnote is written inline in the document. There are Scrivener footnotes where the footnote text is displayed in the footnote sidebar of the Scrivener window.
If I edited an MMD document on an iPad, is there a mechanism to have my MMD footnotes converted to native Scrivener footnotes?
Is there a mechanism to take the native Scrivener footnotes and convert them to MMD footnotes?
If I am entering text on an iPad and Scrivener, what recommendations do you have for managing footnotes? Should I code them all as MMD references?
Actually Scrivener supports both inline footnotes and hidden footnotes. When working with an iPad, as mentioned above, I recommend using Scrivener’s inline footnotes as those can round-trip to plain-text. Linked footnotes cannot (they require too much information to be cleanly expressed in plain-text).
Not directly, but if you converted the MMD document to RTF somehow (with real footnotes), then you could import it into Scrivener that way—of course that drops the rest of the MMD formatting as well.
Compile is the only way.
No, I mean you could easily enough, but if you want to use Scrivener’s regular footnoting features, then it would be better to use the {{…}} notation in conjunction with Scrivener’s sync tools. Just don’t both with the MMD syntax at that phase of the project (it’s kind of hard to type in on an iPad, anyway, with all of that deeply nested punctuation keyboard stuff you have to do).
Thanks very much, @AmberV. After asking my question, I looked it up in the manual. I couldn’t tell from the manual about the limitations of conversions.
Could you please make a footnote to add some information to the Scrivener reference manual about this topic? I suggest a chart listing all of the MMD directives and saying what happens when a document with the directive is encountered during an import. A second chart should say what happens on the compile/export of a MMD document. Part of the problem is that we’re pretty clueless about markdown/MMD in general (at least I am).
I also appreciate your suggestion that there may be different phases to your workflow in entering and editing a paper. When there are entry/editing devices with different capabilities, that’s as important a factor as anything else in establishing a workflow.
Hmm, I don’t know, there really isn’t much that Scrivener does. Via normal import and plain-text sync, it does nothing at all save for its own interpretation of ((comments)) and {{footnotes}}; neither of which have anything to do with MMD. The only import command that even looks at MMD at all File/Import/MultiMarkdown File... does precisely two things: (a) reads each header line and turns it into an outline node at a depth based on the original header depth, and (b) splits the Meta-Data block at the top of the file into its own item at the top of the imported list of items. No other internal markings are touched or converted.
It is true that compile does more, though. There is a whole section on compilation that I intend to write here once the Windows stuff is out of the way, which will discuss various workflows such as e-books, POD, MMD, and web publishing—all of which use non-obvious collections of features working together in concert to do something very specific. The new template and compile preset built-ins in 2.1 do help with this; but this topic needs documentation in general. So I do already have something along these lines on my list.
That and well, the whole MMD chapter in general is pretty paltry. That rewrite is waiting for the MMD3 integration changes to be designed and developed. No sense in putting in a lot of effort right now for what is a deprecated MMD version.
So yeah, overall I’m well aware of the fact that the manual isn’t as friendly to MMD users as it could be. Since MMD users tend toward being a bit more computer savvy, it has probably suffered in that condition longer than it should have, due to getting deferred by other tasks that come along and take up time.
My point is that an increasing number of MMD users are using it because they have few alternatives to enter markup information on their tablet computers. I suspect those users will be very different from the first wave of MMD users – the newbies may have no idea what information can be stored using MMD. Putting a table in the manual gives them a clue what kind of functionality is available in MMD. A strong recommendation to read the MMD manual should be repeatedly noted in the Scrivener manual.
Someone who is trying Scrivener on the 30-day trial asked me for recommendations on entering text and metadata like footnotes on his iPad. AFAICT, there are no elegant solutions to that problem at this point.
I suspect those tablet computer users who are researchers will have a strong prejudice for completely and correctly entering the footnote data the first time. You commented on the nastiness of manually keying an MMD footnote reference. Designers of MMD text editors for the tablet computers would be wise to create a some means (a pop-up form?) for entering footnote data into documents. I’m thinking out loud here; this is clearly tangential to Scrivener. For researchers reading this note: If researchers want features like this on your tablet computer, you must request them from the software developers.
The obvious long-term solution is to be using the same program on laptop and handheld devices and obviate the need for any importing or compiling to synchronize input from multiple devices.
Once again I am thoroughly impressed with the breadth of issues that Scrivener tackles.
The best round-tripping for footnotes is, as AmberV mentioned, the Scrivener in-line footnote.
If you create the in-line note in Scrivener then sync the document to an iPad the in-line note appears as:
{{note text}}
which is easy enough to work with. You can use the same syntax to add notes on the iPad, which then become in-line notes on sync to Scrivener.
And finally, when you compile the document out of Scrivener, those same in-line notes become MMD notes in all their square bracketted glory.
For entering MMD on the iPad I’d strongly recommend WriteRoom which has an extra, configurable, row on the on-screen keyboard: mine currently contains: []{}*#<>
No more hunting three layers down when I need an *.
to add some information to the Scrivener reference manual about this topic? I suggest a chart listing all of the MMD directives and saying what happens when a document with the directive is encountered during an import. A second chart should say what happens on the compile/export of a MMD document. Part of the problem is that we’re pretty clueless about markdown/MMD in general (at least I am).