Fountain X-Header

[rnkn]

Original thread here: lmparppei/Beat#152

A problem encountered by many Fountain developers is how to store additional data within a source file while adhering to the Fountain 1.1 specification. This brings about the competing goals of adding features to one’s own app while maintaining a position of app agnosticism within the Fountain ecosystem.

Proposal

My proposal for a Fountain 1.2 specification is to include the following example format in the metadata/title page headers:

Title: My Script
X-Header: Value

The addition to the spec is that a Fountain app ignores and does not print on the title page any header line beginning with:

X-

Any header beginning with X- is considered an “extension” and will never become an official part of the spec (that is, the full header including the prefix X- will never become an official part of the spec).

An app is then free to implement any key-value specific to their app.

There is no other restriction on how a Fountain app implements their key-values. For example:

Title: My Script
Author: Paul W. Rankin
X-Fountain-Mode-Locked-Pages: yes
X-Highland-2-Goal: 750 words
x-revision: 4
X-app-multiline:
    All work and no play makes Jack a dull boy.
    All work and noplay makes JACK a dull boy.

These come at the BOF just like regular title page metadata. Further:

• Headers are case-insensitive, i.e. X-HEADER is the same as x-header
• Headers may come in any order
• Headers for different Fountain apps may coexist
• Headers may contain indented multiline values consistent with the 1.1 spec
• There is no other restriction on header values
• There is no restriction on how headers are named after the X-
• Including the app name is not required but encouraged to prevent naming collisions
• Multiple apps may use the same header if desired

This implementation follows the precedence of extensions to email headers as detailed in RFC822. It is clear to the user that this metadata belongs to the functioning of an app, and upon printing output it is clear that these values are not printed on the title page. They can safely be ignored or deleted.

An app may choose to show or hide any X- header from the user for possible aesthetics/usability. This is left to the developer’s preference. X- headers demand no special treatment.

How does the user interact with X- headers?

There is no restriction on whether a X- header is added/managed by an app or a user. Like all Fountain specifications, this format is designed to be user-editable. For example, a simple header may only be added by a user:

X-Locked: yes

An app may choose to show or hide any X- header from the user for possible aesthetics/usability reasons. This is left to the developer’s preference. X- headers demand no special treatment.

What do I need to do?

In order for this format to become supported all is required from any Fountain developer is that their app ignore any metadata header beginning with X- from printing on the title page:

X-Anything: this line ignored

If your app already limits what is printed on the title page to a select few metadata header values there is nothing to do.

Any further implementation, i.e. how your app handles specific X- headers and what they signify, is completely up to you.

Current Compatibility

An app is considered compatible with this spec if it does not print an X- header on the title page.

App	Compatibility
Fountain Mode	No
Highland 2	Yes
Beat	No
afterwriting	No
Screenplain	Yes
Wrap	Yes
TextPlay	Yes
BetterFountain	Yes