I have been giving a lot of thought to structural definition within Scrivener. As you know, I am a proponent of structure over style. When given the choice between using a mark to define a type of text, over a font change to describe the type of text, I will take the mark any day. This is one of the primary abilities that drew me to Ulysses, back when I first stumbled across it. It provides a very simple way (for the most part) to mark up your text document with structure, which can then during the export phase, be defined as style.
While I enjoy that ability, I am not completely convinced that the only format a writer needs is text only. Font styles can indeed be useful. I find use for styles as another layer of meta-data, in a similar vein to how Ted G. of About This Particular Outliner fame, supports the usage of named styles. In this school of thought, style then becomes a marker for visually expressed meaning; meaning which does not need to be conveyed at the publishing phase. A simple example would be commentation, and types of commentation within that category. Scrivener’s use of adornment and colour to set apart commentation and citation is a good example of an automated “named style” system. One could also argue that the highlighter tool is another example of meta-data styling. Beyond the built-in tools, Scrivener’s use of the RTF format allows further use of this system in an informal sense, as the author sees need for it. Ulysses lacks this ability completely, having opted for plain text.
Where Ulysses lacks an infinite style potential, it gains in its fairly strong structural export model. Paragraph level mark-up can be transformed into a number of different types, such as headers, lists, block quotes, or deleted entirely; treated as comments. Character level mark-up can be ignored, or transformed into font based styles. Conversely, where Scrivener has an open book on style, the exporter has zero awareness of internal document structure, opting to merely pass format rules to the export engine, where it can be converted into various formats. Even more detrimental, it is impossible to discard what may be wholly irrelevant styling, reducing the effectiveness of its infinite styling potential.
Back in the SG days, I campaigned a little for some form of structural support, with little luck. And lacking any good method (short of a massive departure from Scrivener’s philosophy and a complete “from the foundations” design of the exporter), I let it drop. But just the other day I had an idea. Something that would actually be very easy for you to implement, which would allow structural writers and format writers to coexist. You would not even have to research XHTML, let along LaTeX! Here is the idea, and its ancillary features:
In a word: Markdown. For those not familiar, Markdown (or Textile), is a drop-dead simple method for creating full mark-up from a text file which has had minimal structure applied to it, using (mostly) standard conventions for ASCII embellishment that have existed for decades. Anyone that has been sending email before the advent of HTML, recalls doing simple things like putting asterisks around things you wish to emphasise. Markdown is no more complicated than that. I can make a chapter title like this:
Or, if I preferred to take a more flexible approach, like this:
# Markdown Usage #
So, how could Markdown integrate with Scrivener? There are several issues to be considered. The key issue with integration is that documents which have been structured with style changes have to go through a different exporter than documents which have been styled with Markdown. The documents which go through the Markdown fork will have all of their font styling completely ignored. This fully restores Scrivener’s infinite meta-data potential, so you certainly would not want to pass standard documents through that layer. On the other hand, the method for conversion that Keith is using for exporting is somewhat of a black box, so he could not (without a ton of work) hack a Markdown filter into the standard exporters, and besides, integrating both philosophies into one exporter would reduce the potential of a structurally designed document.
Alternative 1) A battery of Markdown based exporters is added to the export dialogue. Thus, if you used Markdown to structure your novel, you would choose “Markdown to RTF” in the exporter, or “Markdown to XHTML,” whatever. This method would result in a very long, and potentially confusing export format list.
Alternative 2) Rather than make individual choices to the export format, leave that list the way it sits, and instead have a checkbox in the export dialogue which informs the exporter to use the Markdown versions of these exporters. When this checkbox is clicked, the export engines are silently switched behind the scenes, but the list of choices remain the same. It is much less confusing for the user. However, there is a flaw with this and alternative 1: It forces the user to choose between philosophies for every single document in Scrivener that will be exported. This would, even for a structural fiend such as myself, be restricting. While I am a big supporter of structural for most types of documents, there are certainly cases where I do not see any need for it at all, and simple font based styling is all I want. If the project were toggled one way or the other, I would have to sacrifice flexibility.
Alternative 3) While this would require a bit more work on Keith’s end, it would be the most flexible and useful option. In this scenario, a checkbox is added to each document in the Meta-data section of the Inspector, right above the date stamp. This checkbox would enable Markdown formatting for that document. Optionally, as a time-saver, each document could reference its parent, and inherit the checkbox automatically. This could of course be over-ridden. Then, during the export phase, the export system would check for that flag, and if it was enabled, that document would be passed through the Markdown version as opposed to the standard version. Say the user selected RTF format, they would end up with a directory full of RTFs, completely ignorant of which system it went through by that point. The except would be plain text export, which would not do anything with Markdown (the syntax would be preserved).
The particulars of the Markdown export engine are quite simple. It would require two functions (I believe). The first would convert the working stream to plain text, and in the process convert annotations and footnotes (and potentially links) into appropriate Markdown syntax or plain text alternatives (such as how brackets are used, though brackets have special meaning in Markdown). Layer two would make use of MultiMarkdown.pl, which allows a variety of export types. Standard Markdown only converts your text to XHTML, but with MultiMarkdown, we can get functional LaTeX, and RTF documents.
To handle LaTeX, which can only be done with Markdown and not the RTFD style documents in Scrivener, perhaps a checkbox option in the export dialogue to over-ride the export format choice to LaTeX for all Markdown based documents in the export. That way, you can choose a format for basic export.
The actual export process would basically just be piping the documents through the shell commands, very little development would be required.
That is basically it. So what do you think? This could all be made very simple for the user. Versions of the Markdown Perl scripts could be distributed inside of Scrivener. See TextMate for examples. TextMate has a full Markdown bundle, with a bundled version of it and MultiMarkdown, some syntax aids, and a full range of export options. The Bundle editor reveals the syntax used to create these various exporters.