Fountain for Sublime Text

Jonathan Poritsky has created a great Fountain package for Sublime Text. It supports almost everything outlined in the Fountain syntax guide but, most importantly, gives us syntax highlighting.

While not everyone likes the idea of using colors to highlight elements in their screenplay, I most definitely do. For me, syntax highlighting is equivalent to the red squiggly line underneath a misspelled word. At a glance, I can see if I've made any errors and, to a lesser degree, I can recognize patterns of highlighted elements to quickly understand where I am in the overall document.

Another reason I want syntax highlighting is to ease my recent transition to full-time use of Fountain for screenwriting writing projects, replacing my roll-your-own MultiMarkdown screenplay syntax.

The Part Where I Ruin Everything

Hands down, my favorite part of Jonathan's Fountain package is its ability to be customized, like all Sublime Text packages. The default package theme does a good job of emulating the look of a screenplay, using layout settings like 15pt black Courier on a white background and centering the text within the document window, etc.

While I enjoy reading screenplays in their correct format, I really dislike that layout during the writing process. I much prefer to look at white text on a black document. More specifically, I use the Sunburst theme in Sublime Text while writing in MultiMarkdown. Since Fountain is designed specifically to be platform and application agnostic, I'm free to be as picky as I want about my writing environment.

So, I tweaked the theme that came with the Fountain package. The biggest thing I wanted to add was background highlighting for Scene Headings. It helps me quickly scan the document to find the beginning of a given scene.

View fullsize

I made all Scene Headings, Action, Character, and Dialogue elements white(ish), and Parentheticals, Sections, Synopses a dimmer grey color to help them fade into the background a bit. The only elements that use colored text are Transitions, Notes, and the Title Page, which uses the same color scheme as MultiMarkdown metadata in the Sunburst theme.

In Fountain.sublime-settings I removed the additional line padding, changed the font to Monaco 11, turned on line numbering, and turned off "draw_centered". What I'm left with is a document that looks nothing like a screenplay, just the way I like it.

Personally, I don't want to feel like I'm writing a screenplay. Writing a screenplay is hard and stressful. Conversely, writing words into a text editor is something I can do all day long. Maybe some day I won't be so particular or need to psych myself out in order to write, but for now, this feels right to me and I'm sticking with it.

If for some reason you would like to use my theme, download this file and drop it into the Fountain folder in your Sublime Text package directory. Once you've done that, open up Fountain.sublime-settings and make yours match mine:

{  
    "extensions":  
    [  
    "fountain"  
    ],  
    "font_face": "Monaco",  
    // "font_face": "Courier Screenplay",  
    // "font_face": "Courier Final Draft",  
    "font_size": 11,  
    "color_scheme": "Packages/Fountain/Fountain Dan.tmTheme",  
    "word_wrap": true,  
    "wrap_width": 78,  
    // "line_padding_top": 5,  
    "draw_centered": false,  
    "spell_check": true,  
    "indent_subsequent_lines": false,  
    "trim_automatic_white_space": true,  
    "line_numbers": true,  
    "translate_tabs_to_spaces": true,  
    "auto_complete_commit_on_tab": true,  
    "auto_complete_with_fields": true  
}

Launching Marked from Sublime Text 2

I do pretty much all my MultiMarkdown writing anymore in Sublime Text 2. I’ve come to rely on Marked for previewing my files with a variety of custom CSS files, depending on the type of project I’m writing.

At the moment, the most annoying part of this workflow is the time it takes to open Marked and locate the MultiMarkdown file I’m currently working on in Sublime Text. I think I’ve been spoiled by the speed of using Sublime Text’s Goto Anything feature (Command + P) for opening files.

To speed things along, I wrote a new build system for Sublime Text that launches the active document in Marked. Now previewing my active file is as easy as invoking the build command which, for me, is still Command + B.

The (insanely simple) code [1]:

{  
"shell": "true",  
"cmd": ["open -a marked \"$file\""]  
}  

More non-rocket-science, but a big time saver in my world.

---

1. This build system is only for OS X.  ↩

Automated FTP upload with Hazel via Bash

A couple weeks ago Macdrifter had a nice post about automating FTP uploads with Hazel, Dropbox, and Python. It’s a similar idea to the setup I’ve been using to automate my MultiMarkdown workflow, but the main reason it grabbed my interest was this line:

I really like Transmit for FTP, but it seemed a little heavy handed for Hazel automation.

He’s right. Using Transmit for the FTP portion of my process was a poor decision. It just happened to be the only way I knew how, and scripting the FTP upload didn’t even occur to me at the time (there’s a reason for the name of this site).

After reading his post, I decided to swap out the slow and clunky Transmit portion of my Hazel rule with some fancy code. One problem. I don’t know anything about Python[1], and the 3 hours I spent trying to get up to speed were futile and fruitless.

Since I’ve dabbled a bit with Bash, I decided to see if there was an equivalent way to accomplish the same tasks. After a bit of searching, and a lot of trial and error (again, read the name of the site), I came up with this:

HOST=ftp.DOMAIN.com  
USER=myUserName  
PASS=myPassword  

JNAME= \ basename $1\  

ftp -inv $HOST << EOF  

user $USER $PASS  

put "$1" "$JNAME"  

EOF  

echo "http://dansturm.com/$JNAME" >> /Users/PATH/Dropbox/PATH/UPLOADS_LOG_FILE.txt

It’s faster than the Transmit method. It works more often than the Transmit method. And it even records the URL of the uploaded file to a text file in my Dropbox (my favorite idea from the Macdrifter post). I also have the Hazel rule change the file name to all lowercase and swap spaces for underscores, something is already performed in my Text to HTML conversion rule, but now the FTP rule can be used stand-alone as well as in conjunction with the MultiMarkdown process.

It has no error reporting, and you can’t even really tell it’s running (save for the evidence in the log file), but it’s way better than what I was using. Many thanks to Macdrifter for this one.

But…

I’m happy I was able to improve my exiting tools, and learn a few things in the process, but now that I’ve migrated this blog to Squarespace, I’m not sure how much I’ll actually use them considering Squarespace doesn’t support FTP access, and my home site doesn’t need updating very often.

---

1. Okay, I know some Python, but only enough to customize the interface in Nuke and build some basic gizmos and comp tools.  ↩

Creating Linked Images with TextExpander

I have a TextExpander snippet for creating Markdown links. I have one for creating Markdown images. Both pull a URL from the clipboard.

On occasion I’ve used them in combination to create images that are linked to the, usually larger, original images. I don’t know why it’s taken me this long to create a single snippet to do this one task, but a recent project filled with high-rez images necessitated such a tool.

For this particular project, I’ve also used a fill variable to add a description to the image. Not rocket science, but just another tool to save myself a lot of time and frustration.

The Snippet:

[![%fill:description%](%clipboard) %fill:description%](%clipboard)

SP-MMD Cheaters

Since Brett Terpstra gave us Cheaters, I’ve been populating the app with the various tools I use frequently.

I’ve finally gotten around to creating a cheat sheet for my MultiMarkdown Screenplay syntax. I expect it to be used by precisely one person. Me.

However I’m posting it here to serve as a shorter explanation of the way I write, to spare you from reading the whole back story. It uses the same modified CSS file I created for the Fountain cheet sheet.

Here’s the SP-MMD Cheaters page.

And here’s the cheat sheet in a web-friendly view for curious passers-by.

My Hazel CMS

It should be no surprise to anyone familiar with the app, that Noodlesoft’s Hazel is amazing. Today I setup an automated system using Dropbox, Automator, and Hazel to process MultiMarkdown documents into HTML, give them web-ready filenames, and upload them to my website.

Everything on this site starts as a MultiMarkdown text file. I preview the page in Marked, and when its ready to go live, I save a copy of the file in a folder called _1_ready_, which has 3 Hazel rules applied.

Ready

First things first, the text file needs to be converted to an HTML document. I’ve used the Run Shell Script action to call the mmd command.

Pretty straight forward. To add some flexibility, the second Hazel rule for the _1_ready_ folder checks for changes to preexisting text files, and processes them using the same bash script. That saves me from having to delete and re-copy a file to make an update.

The last rule for the _1_ready_ folder renames the HTML file, making it entirely lowercase, replaces the spaces with underscores, and moves the new file to a folder called _2_go_.

It’s important to make sure the name element in the with patern: section is set to lowercase, and the replace text dialog is used to swap the spaces for underscores.

Go

The _2_go_ folder automatically uploads any file it finds to the root of my site. As with _1_ready_, the final files are left in the folder to more easily make changes later. Additionally, I keep a copy of my Blog index page and rss XML in the _2_go_ folder so I can quickly update the main page with links to the new posts.

To upload the files, the Hazel rule calls an Automator Workflow that uses the Transmit [1] upload action to log into my site (stored as a favorite), and drop everything in the root folder, overwriting files if necessary.

Dropbox

The best part about this whole workflow is Dropbox. Both the _1_ready_ and _2_go_ folders are in my Dropbox, giving me the ability to drop in files from my iPhone, iPad, etc. With apps like TextExpander and Nebulous Notes, there’s no reason I can’t create, and post entirely from an iOS device. Obviously I’ll need a Mac, running and online, but the flexibility of this workflow is well worth the cost of a dedicated system.

Needless to say, I’m incredibly excited to have this new capability, and I can’t wait to see what other workflow magic I can create with Hazel

---

1. Many thanks to Macdrifter for recommending Transmit. I love this app.  ↩

Update: I've since revised my upload method to use a Bash script, rather than Transmit. It's much faster and more efficient, so if this idea interests you, you should definitely check it out.

MultiMarkdown Build Systems for Sublime Text 2

When I started using Sublime Text 2 as my primary text editor, last year sometime, I created a build system to more quickly process my MultiMarkdown files. Since I couldn’t find a preexisting MultiMarkdown build system in the Sublime Text forum, it’s probably a safe bet that others might find it useful for me to post mine.

Since all of my writing is based on MultiMarkdown and varying CSS files, I use the same build system for screenplays, blog posts, presentations, etc. When I created the initial build system I was doing the majority of my writing on a Windows 7 machine. Since that time, I have retired all of my Windows computers [1] and created a new build system for OS X (10.7.3).

Here are both build systems:

OS X

{
"shell": "true",
"path": "/usr/local/bin",
"cmd": ["mmd \"$file\""]
}

Windows

{
"shell": "true",
"cmd": "multimarkdown -b \"$file\"",
"cmd": "\"\"${file/\\.txt/\\.html/}\"\""
}

The last line in the Windows build system is a launch command that will open the processed document in your default HTML application. Since I have Marked on my Mac, I decided to omit the launch command from the OS X version and pick my viewer on a per-file basis.

---

1. For a number of reasons, I’m still required to use a VM of Win 7 on my Mac via Parallels.  ↩

Fountain for Cheaters

Earlier today Brett Terpstra posted Cheaters, a “customizable cheat sheet system”. It’s easy to use, super helpful, and just all around awesome.

I had a little time this afternoon so I whipped up a Fountain syntax guide, pulled from the fountain.io syntax page. Here are links to the Fountain sheet and the modified CSS file. Follow Brett’s instructions to customize your own cheatsheet.

I plan on adding my SP-MMD syntax to my cheatsheet, as well as my still-in-development MultiMarkdown sildeshow presentation tool.

FYI, since I’m strictly an amateur, I make no guarantees that this will work as well for you as it does for me.

A huge thanks to Brett for this insanely useful tool.

No More Excuses

In my continued quest to create a completely application independent writing workflow, I figured I’d share a tip that has helped my adoption of MultiMarkdown. This is a simple one, but it’s one of those things that may not be completely obvious to new users.

I still get blank stares of confusion from people when I try to explain MultiMarkdown and just how great it is for creating pretty much anything that includes words. I imagine the difficulty has something to do with new users not quite seeing the cost / benefit to completely overhauling their writing workflow. The Dropbox syncing and platform independence of text files are a great opening line for the sales pitch, but I think the features MultiMarkdown brings to the table are the real closers.

The primary reason I continue to favor MultiMarkdown over traditional Markdown is it’s implementation of document metadata. First off, I love that it creates a nice, neat header to all my files. It’s really the only way I can tell what I’m looking at as I quickly fly through files with the ‘Goto Anything’ feature in Sublime Text 2.

But since I’m attempting to replace all of my writing tasks with MultiMarkdown, the most important metadata feature for me is the CSS key. I can quickly link to different CSS files to create the type of output I’m looking for. I have a standard CSS file for writing on my site, one for converting MultiMarkdown documents screenplays, and most recently I’ve created one that outputs something akin to a slide presentation [1], to remove the need for horrible presentation software that will not be named here.

Now, since I’m a good nerd, I use TextExpander to take care of the heavy lifting of the MultiMarkdown header syntax. When I open a new text file, I use the snippet ‘mmeta’ to trigger the following:

Title:                 %|
Author:             Dan Sturm
Date:                 %snippet:ddate%
Keywords:
CSS:                    http://dansturm.com/ds_doc.css

I now have a date stamped file, linked to my default CSS, ready to for me to add a title and any relevant keywords. If I’m writing a screenplay instead of a web post, all I have to do is change ‘http://dansturm.com/ds_doc.css’ to ‘http://dansturm.com/ds_script.css’. And soon, it’ll be just as simple to switch between web posts, screenplays, and slide presentations.

I like using CSS to modify the output of my simple MultiMarkdown documents. I don’t need to learn a different syntax for each type of file I want to create. With a couple hours of tweaking and testing, I can create additional CSS files for nearly any output I may deem useful. And this is all in addition to the obvious benefit of using basic MultiMarkdown and simple CSS to keep my amateur brain from exploding.

Yes this is all very basic stuff, I know. My point is this; when creating a properly formatted document, in any style you desire, requires as little effort as typing ‘mmeta’, there’s really no excuse for using a word processor, screenplay writing application, or slideshow application.

I hope this will help you make the leap to using MultiMarkdown full time in your own writing. I can’t begin to explain how much I love and rely on it every day.

---

1. Post coming soon.  ↩

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.  ↩