DEV Community: ShikiShiki

Paginating a screenplay is a fixed-point problem

ShikiShiki — Wed, 02 Sep 2026 15:22:14 +0000

A screenplay page holds about 55 lines of 12 point Courier. Break the script every 55 lines and you have pagination.

That works until a block of dialogue lands on a boundary. Then the format demands two extra things. The bottom of the page gets a (MORE), and the top of the next page repeats the character name with a (CONT'D):

                    SARAH
          I told you this would happen. I
          told you in the car, I told you
                    (MORE)

          - - - - - page break - - - - -

                    SARAH (CONT'D)
          at the door, and I am telling you
          now.

Those two markers are content. They take up lines on pages you already measured. So the break you just computed was computed against a line count that is now wrong.

The layout depends on its own output

Pagination looks like a chunking problem, so that is how everybody writes it the first time:

// the version everybody writes first
function paginate(lines, perPage = 55) {
  const pages = [];
  for (let i = 0; i < lines.length; i += perPage) {
    pages.push(lines.slice(i, i + perPage));
  }
  return pages;
}

But the real function is not layout(content). It is closer to

pages = layout(content + continuations(pages))

pages appears on both sides. You are not chunking a list, you are looking for a fixed point.

Why one extra pass is not enough

The obvious patch is to run the chunker, see which dialogue blocks got split, insert the markers, and run it again. Two passes, done.

It is better. It is still wrong, because the second pass creates splits the first pass did not have. You added lines, everything after the first split shifted down by two, and something that used to end comfortably mid-page now hangs off the bottom. New split. New markers. New shift.

The churn is worse than it sounds, because the other formatting rules also move content down and never up:

A scene heading needs at least two lines of the scene under it. Alone at the bottom of a page, it moves to the next one.
A dialogue block that breaks must leave at least two lines on each side of the break. One orphan line is not allowed.
You cannot break between a character cue and their first line.
You cannot break inside a parenthetical.

Each of those pushes a block forward, and each push can open a gap that lets a different block fit where it did not fit before, which pulls it back, which pushes the next one forward. Implement the rules as a straight loop with no discipline and you can watch it oscillate between two layouts forever.

Iterating to a fixed point, and making it stop

The trick that makes this terminate is monotonicity. Track the set of dialogue blocks known to break, and only ever add to it. Never remove one because a later pass made it fit.

function paginate(elements, perPage = 55, maxPasses = 8) {
  const splits = new Set();

  for (let pass = 0; pass < maxPasses; pass++) {
    const pages = layout(withContinuations(elements, splits), perPage);
    const observed = findSplitDialogue(pages);

    // every split we saw is one we already knew about: fixed point
    if ([...observed].every((s) => splits.has(s))) return pages;

    for (const s of observed) splits.add(s);
  }

  throw new Error("pagination did not settle");
}

The termination argument is short. splits only grows, it is bounded by the number of dialogue blocks in the script, and every pass that does not return adds at least one member. So the loop ends.

You give up something for that guarantee. A block marked as split on pass two might genuinely fit on one page once everything settles, and you keep the (MORE) anyway. In exchange you get a layout that is stable and reproducible, which matters more than saving one line, because two people opening the same script have to see the same page numbers.

In practice it settles in three or four passes. If yours needs eight, one of the widow rules is fighting another one and the bug is there, not in the loop.

Why anyone should care about two lines

Because the page count is not cosmetic. The convention is one page, one minute, and the industry budgets against that number: shooting days, crew, insurance, the schedule. A 110 page script is a 110 minute film until someone proves otherwise.

Do the arithmetic on a dialogue-heavy script. Forty split blocks, two lines each, is eighty extra lines. At 55 lines a page that is a page and a half of runtime a single-pass paginator never reports. Not a rounding error. A day.

Checking your own numbers

I keep a few of these as browser tools, no account needed, mostly because I got tired of opening a full editor to answer one question.

Script time calculator, page count and runtime, for a second opinion on what your paginator says.

Screenplay format checker, for the widow and orphan rules above.

Fountain to PDF, which runs the fixed point described here and shows the breaks it landed on.

Scene extractor, to pull the element list out of an existing script if you need test data.

If you are building a renderer and want to compare page breaks against another implementation, the Fountain converter is the useful one. Feed it something with long speeches near a boundary and see whether you agree.

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

ShikiShiki — Wed, 02 Sep 2026 13:38:19 +0000

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:

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.

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:

script time calculator, the one page one minute estimate
screenplay format checker
Fountain to PDF
scene extractor

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.