Home

You’re Doing That Wrong is a journal of various successes and failures by Dan Sturm.

My MultiMarkdown SPMD Workflow

MultiMarkdown and SPMD

Back in August when Stu Maschwitz proposed Screenplay Markdown (formerly SPMD, now Fountain), I got very excited. After giving Stu way more input than he needed, I decided I wanted to use something like SPMD sooner rather than later.

Due to my lack of any real programming skills, I decided the quickest way to get something usable was to continue writing in MultiMarkdown and use simple CSS to transform my output into something that looked like a screenplay.

My solution is in no way as robust or polished as Stu’s SPMD proposal, but having used it for a few months now I find it suits my needs pretty well. You can find my SP-MMD(?) CSS file here.

Why MultiMarkdown?

There are a few reasons I chose to use MultiMarkdown instead of standard Markdown syntax. The first reason is it’s inclusion of metadata and the ability to create a “complete document” rather than just an HTML “snippit”.

From the MultiMarkdown user guide:

If you include metadata in your document (with two exceptions), then you will generate a complete document. If you don’t include metadata, then you will instead generate a “snippet.” The snippet will just include the relevant portion of HTML, but will not include the <head> or <body> elements.

The metadata features give me a nice looking header to all my text files and, more importantly, creates a complete HTML document that’s ready for the web. You may be asking, “But why does it need to be ready for the web? It’s a screenplay.” As much as I love writing in my text editor, eventually I will need to preview the final output of the properly formatted document.

Previewing

Ideally to view the final document I’d use something like Brett Terpstra’s awesome Marked app. But, unfortunately, I do the majority of my writing on a Windows 7 machine (please don’t email me [1] ). Regardless of the operating system on the machine itself, I like the idea of doing my previewing in a browser for two reasons. First, let’s face it, any computer you sit down at these days is going to have at least one browser installed, and that’s just one less app I need to worry about installing for my workflow to function properly. The second reason I user the browser for previewing is print support. MultiMarkdown supports some great text to pdf conversion tools through LaTeX, but the simpler solution is simply to print to PDF directly from the browser preview.

Another benefit of creating an HTML document from my text file is the ability to quickly upload it to my website and send a link to people. Having that online backup saves my ass when I’m away from a computer and someone who has lost their copy needs to read my script ASAP. Of course I always have my iPhone with me and I can easily resend the PDF via Dropbox, but that takes longer than just emailing or texting a URL.

CSS

The other huge advantage to using MultiMarkdown is the CSS metadata key. While Markdown is capable of using standard HTML code within the document, I much prefer the cleanliness and simplicity of the MultiMarkdown implementation.

Example. To link my CSS file in a standard Markdown file, I can use the line:

<style type="text/css"> <!-- @import url("http://dansturm.com/ds_script.css"); -->    </style>

Not exactly something I love to see at the top of all of my text files. With MultiMarkdown it’s as simple as:

CSS: http://dansturm.com/ds_script.css

Much better. And being that it’s cleaner to read, if I want to switch to a different CSS file for different formatting, I can more quickly and easily modify the URL.

My SP-MMD Syntax

The next problem MultiMarkdown solved was the fact that I would simply be using existing Markdown syntax elements in ways they were never intended, rather than creating my own language from the ground up. MultiMarkdown solves that problem by having additional syntax features not found in Markdown.

Standard MultiMarkdown *italics* and **bold** syntax is preserved. There is currently no support for underline text.

Basic Action elements of the script have no additional syntax associated with them (just as in Stu’s SPMD) and only required basic margin adjustments to the <p> tag to create the correct looking format.

For other elements of a screenplay I need the ability to have things left, center, and right justified. I appropriated the H1, H2, and H3 tags for this purpose. Examples:

For things like scene headings (left justified via H1), I write:

# Int. Coffee Shop - Day

Since scene headings should be written in CAPS, we can use the magic of CSS and the text-transform: uppercase command to automatically capitalize the line. It may not seem like a big deal, but it’s automating small things like this that allow me to keep my mind on the words and not the formatting.

Elements needing center alignment like the script’s title (NOT characters or dialog), use the H2 tag:

## Fancy Screenplay
## By Dan Sturm

Centered text is different from left or right justified text in that it is not subject to auto capitalization. I felt it’s content needed to be flexible.

And, as expected, right aligned text is written as:

### Cut to

Now for dialog. I needed control over both Character and Dialog elements separately, but I didn’t want each to require different syntax modifiers. As luck would have it, MultiMarkdown’s support for Definition Lists fit this need perfectly. To write dialog the syntax is:

Dan
: Is this guy completely insane?

Using just a colon before the dialog (and no spaces following the character) gives the character name the <dt> tag, and the dialog receives the associated <dd> tag. Again, by way of the text-transform: uppercase command, our character name is automatically capitalized. Two script elements defined by a single syntax character. Just what I was looking for.

To add a parenthetical to a line of dialog, I used the code-block designation of surrounding the line with backticks. I wish additional syntax wasn’t necessary for parentheticals, but at the moment this is the best way I could get the result I needed. Example:

Dan
`(pointing)`
: Is this guy completely insane?

Since there’s really no built in tool for pagination of HTML files, I felt a need to create a tool to force page breaks. A horizontal rule is all that’s required to force a page break. The forced page breaks are only visible when the document is sent to print, but I think the horizontal rule does a decent enough job of communicating the page break in the browser.

Known Issues

Since I put this little project together in a couple hours one night, when it reached the point of being “usable”, I stopped working on the code and went back to writing my script. As expected, there are a few known issues that may or may not be deal breakers for you.

The first issue is related to margins. When printing from the browser, I cannot print all the way to the edge of the paper. If there’s a way to create a full bleed PDF from a browser, I haven’t found it yet. Why is this a problem? My CSS originally assumed a full 8.5“ x 11” piece of paper from which to base it’s margin adjustments for each element. Printing from the browser scales that full size image down to something closer to 8“ x 10.5” ruining the rest of the formatting. I’ve attempted to compensate for those margins, but since I’m not 100% sure how large the margins the browser is adding actually are, it’s just guesswork. I plan to revisit this problem in the next rev of the CSS.

The next issue is one that doesn’t really affect me in the writing I personally do, but may be an issue for others. When creating parentheticals within a line of dialog (i.e. not immediately after the character and immediately before the dialog) the resulting margin is incorrect. Since I don’t currently have a method for determining where in the dialog the parenthetical occurs, there is no workaround for this issue. Example of writing that creates a problem:

Dan
: Is this guy completely insane?
`(pointing)`
: Or is he just full of it?

Again, something I plan on revisiting in the future.

Currently Unsupported

In my implementation there is currently no support for the following screenplay elements:

  • Dual Dialog
  • Sections and Synopses
  • Underlined Text

Pain Vs Flexibility

If you still think this whole idea is crazy and way more painful than the associated benefit, allow me to share a few tips and benefits.

As any good writing nerd, I use TextExpander (and Breevy on the PC) to alleviate some of the pain of the syntax. Page breaks via horizontal rules are added by typing “hhrl”, which creates 5 asterisks. I use “iint” to create “# INT. (FILL-BOX) - (FILL-BOX)”. I have about a dozen snippets that automate frequently used screenplay syntax (and correct typos). Another great benefit of using TextExpander is the ability to have a snippet turn CAPS on and off as needed. And if I somehow manage to override the CAPS on any particular line, the CSS will correct my mistake for me. Again, another small tool that helps keep my mind on the words.

Another reason I love this process may be a bit of blasphemy to many of you, but since it makes my life easier, it may do the same for some of you. At the very bottom of my scripts is usually a page break (horizontal rule) followed by a list of links to other relevant files the customer may need to see. Here I add links to storyboards, budgets, video reference, etc. And since it follows a page break, it’s easy enough to leave out of the printed version by designating a page range in the print dialog box. I love having a linked list of important files directly attached to the screenplay because, frankly it’s one less email I have to receive from the customer who loses their copy of those associated files.

No, I’m Not Crazy

In summary, yes, this is a really weird way to write a script and yes, it probably seems like more work that it’s worth, but I really believe the benefits and flexibility of MultiMarkdown and CSS greatly outweigh the hassles, even if my current implementation is far from ideal. If you think this mess will work for you, feel free to use, copy, steal, or modify my CSS file. And I’ll be sure to let you know if I ever get around to making v0.02.

To close, here’s how a sample script would look in my SP-MMD format.

Title: Fancy Script
Author: Dan Sturm
Date:
CSS: http://dansturm.com/ds_script.css

## FANCY SCRIPT
## By Dan Sturm

* * * * *

# EXT. GAS STATION - DAY

A bright hot day. A truck pulls up to the pump. The DRIVER steps out and heads inside.

The PASSENGER lights a cigarette and waits.

Eventually, the DRIVER bursts out the gas station door, GUN in one hand, MONEY in the other.

Driver
: Start the car!

Passenger
`(under his breath)`
: No shit.

### CUT TO:

# INT. NEXT SCENE - DAY

And Here’s what the above script looks like when formatted

  1. Borrowed, with love, from the great Marco Arment.  ↩