DEV Community

Cover image for Screenplay format is a spec, and most editors quietly break it
ShikiShiki
ShikiShiki

Posted on Fully Autonomous

Screenplay format is a spec, and most editors quietly break it

#parsing #showdev #webdev

A screenplay looks like a badly indented document. It behaves more like a fixed-width data format that happens to be readable by humans.

Developers keep assuming they can render one with a couple of CSS rules. Then a producer opens the PDF, the page count is off, and the page count is the number everybody downstream actually uses.

One page, one minute

The convention is that a correctly formatted page runs roughly a minute of screen time. It is a rough rule and it lies for action sequences, but the industry budgets against it anyway. A 110 page script is a 110 minute film until someone proves otherwise. Scheduling, shooting days, insurance, all of it hangs off that number.

So formatting is not cosmetic. Courier at 12 point is a load-bearing decision. Swap in Arial and every line gets narrower, dialogue reflows, the script "becomes" 96 pages, and the estimate you just handed a line producer is wrong by a quarter of an hour.

The format is a small set of elements, each with its own fixed indentation:

  • scene heading (INT. KITCHEN - NIGHT)
  • action
  • character cue
  • parenthetical
  • dialogue
  • transition (CUT TO:)

Six element types, hard indents, monospaced font, about 55 lines to a page. That is the whole spec, and it has barely moved in decades because too much money sits downstream of it.

Why a word processor is the wrong tool

Word processors let you fake it. You set tab stops, you get something that looks right, then someone opens the file on a machine with different font metrics and the pagination shifts under them.

The deeper problem is that the structure lives only in the indentation. Nothing in the file says "this line is a character cue." You cannot query it, you cannot diff it usefully, and you cannot pull a scene list out of it without writing a parser for whitespace.

Final Draft solved this with .fdx, which is XML and perfectly parseable. It is also proprietary and tied to a paid desktop app.

Fountain

Fountain is the plain text answer. A .fountain file is Markdown-shaped: readable as-is, unambiguous enough to parse, and it lives happily in git.

INT. KITCHEN - NIGHT

ROSE stands at the sink, not washing anything.

ROSE
(quietly)
You said you would be back by six.

MARCUS
I said I would try.

CUT TO:
Enter fullscreen mode Exit fullscreen mode

The rules that carry most of the weight:

  • a line starting with INT., EXT., EST., INT./EXT. or I/E. is a scene heading, and a leading . forces one
  • an uppercase line preceded by a blank line and followed by a non-blank line is a character cue, and @ forces one
  • parentheses directly under a cue make a parenthetical
  • an uppercase line ending in TO: is a transition, and > forces one
  • ^ after a character name marks dual dialogue
  • /* */ is a boneyard and [[ ]] is a note, neither of which renders

The part that bites

That character cue rule is where naive parsers fall over. Consider:

SLAM.

The door rattles in its frame.
Enter fullscreen mode Exit fullscreen mode

SLAM. is uppercase, sits after a blank line, and is followed by a non-blank line. Textbook character cue. It is action, and your parser just gave the door a speaking part.

Fountain's own answer is the ! prefix to force action, which works when the writer remembers. Forgiving parsers stack heuristics on top: demote a cue that never speaks again, or one that is a single word ending in a period, or one whose dialogue block is suspiciously long. Every Fountain implementation I have read has some version of this, and they disagree at the edges.

Pagination is the other trap. You cannot break a page in the middle of a dialogue block and walk away. You close with (MORE), reopen with the character name plus (CONT'D), and both of those consume lines, which can push you past the limit and force another break. It is a fixed-point problem hiding inside a layout engine.

If you want to poke at it

We put a few of these on the web, free and without an account:

They run client side, so the script never leaves the browser. If you are writing a Fountain parser yourself, the format checker is a reasonable oracle for the ambiguous cases.

Top comments (0)