Multicam

[Blake Henry]

Hello,

I applaud the metadata extension to Fountain as it can be used to solve a lot of issues.

First, it could be used to control the Fountain output format to generate standard or perhaps Multicam output similar to Final Draft's 'Templates' e.g.

{{format=feature}}

The quick brown fox JUMPED over the lazy dog.

{{format=multicam}}

THE QUICK BROWN FOX JUMPED OVER THE LAZY DOG.

Also, I would second Paul's motion about allowing variable names within the curly braces e.g.

{{hero=David}}

{{hero}} defeated the giant.

David defeated the giant. 

Maybe it's overkill, but at least the parser can do a consistency check on the document in case there's an undefined variable.  Not sure if you want to go there.

It could also be used to implement alternate dialogue and production revisions.

Good to see the forum with good active discussions. :)

Thanks,

Blake

[Paul W. Rankin]

On 15 Apr 2018, at 10:18 am, Blake Henry <bahe...@gmail.com> wrote:
>
> Hello,
>
> I applaud the metadata extension to Fountain as it can be used to solve a lot of issues.
> First, it could be used to control the Fountain output format to generate standard or perhaps Multicam output similar to Final Draft's 'Templates' e.g.
>
> {{format=feature}}
> The quick brown fox JUMPED over the lazy dog.
> {{format=multicam}}
> THE QUICK BROWN FOX JUMPED OVER THE LAZY DOG.

(I have tended to call the things wrapped in curly braces "directives" to distinguish them from the top-of-file title page data, sometimes referred to as metadata.)

I was under the impression that there was already this functionality using metadata at the top of file, e.g.

title: A Very Big Horse
credit: written by
author: Oscar T. Grouch
format: multicam

However, now that I'm poking around I can't find where I got that impression...

> Also, I would second Paul's motion about allowing variable names within the curly braces e.g.
> {{hero=David}}
> {{hero}} defeated the giant.
> David defeated the giant.
>
> Maybe it's overkill, but at least the parser can do a consistency check on the document in case there's an undefined variable. Not sure if you want to go there.

(This idea actually comes from Piotr who created afterwriting, see https://github.com/ifrost/afterwriting-labs/blob/master/docs/clients.md#snippets)

I think my idea of porting this into the fountain spec was to have variables defined at top of file, e.g.


title: A Very Big Horse
credit: written by
author: Oscar T. Grouch
hero: David

Then use {{ hero }} within the script.

I use this method with internal templates, e.g. in creating HTML output:

<title>{{title}}</title>

Although I'd only expect a writer to use this for maintaining consistency for marginal details that you don't want to stop and think about while writing, e.g. the name of the company the antagonist works for:

title: The Floor is Lava
credit: written by
author: Pennywise Plath
evilcorp: Joogle

INT. {{ EVILCORP }} OFFICE - DAY

However, fountain probably works better if it's grandmother-proof (see https://groups.google.com/d/msg/fountain-dev/qD10HUl1LuE/NnCw8_fRBwAJ).

So with something like this, a writer can achieve the same result by just writing something like $evilcorp then doing a find & replace later. (This is what I would do.)

> It could also be used to implement alternate dialogue and production revisions.

Interesting. Can you expand a little on this?

John has also suggested using for marking revised regions (see https://groups.google.com/d/msg/fountain-dev/Xv54y9jGIA0/q2bieH7yEgAJ). I tend to think it's easier to embed a diff utility in the host application.

> Good to see the forum with good active discussions. :)

It's mostly just me annoying John and Stu.

--
https://www.paulwrankin.com

[Blake Henry]

Hi Paul!

Thanks for your thoughtful reply.  I'll reply inline to your inline reply and I'll try not to get out of line.

On Monday, April 16, 2018 at 3:56:35 AM UTC-7, Paul W. Rankin wrote:

On 15 Apr 2018, at 10:18 am, Blake Henry <bahe...@gmail.com> wrote:
>
> Hello,
>
> I applaud the metadata extension to Fountain as it can be used to solve a lot of issues.
> First, it could be used to control the Fountain output format to generate standard or perhaps Multicam output similar to Final Draft's 'Templates' e.g.
>
> {{format=feature}}
> The quick brown fox JUMPED over the lazy dog.
> {{format=multicam}}
> THE QUICK BROWN FOX JUMPED OVER THE LAZY DOG.

(I have tended to call the things wrapped in curly braces "directives" to distinguish them from the top-of-file title page data, sometimes referred to as metadata.)

 

I stand corrected.  Yes, technically they are directives.   

I was under the impression that there was already this functionality using metadata at the top of file, e.g.

    title: A Very Big Horse
    credit: written by
    author: Oscar T. Grouch
    format: multicam

However, now that I'm poking around I can't find where I got that impression...

I found it.  It's in the 'Title Page' section of the Fountain.io spec page: https://fountain.io/syntax#section-titlepage

 

> Also, I would second Paul's motion about allowing variable names within the curly braces e.g.
> {{hero=David}}
> {{hero}} defeated the giant.
> David defeated the giant.
>
> Maybe it's overkill, but at least the parser can do a consistency check on the document in case there's an undefined variable.  Not sure if you want to go there.

(This idea actually comes from Piotr who created afterwriting, see https://github.com/ifrost/afterwriting-labs/blob/master/docs/clients.md#snippets)

I think my idea of porting this into the fountain spec was to have variables defined at top of file, e.g.


    title: A Very Big Horse
    credit: written by
    author: Oscar T. Grouch
    hero: David

Then use {{ hero }} within the script.

I use this method with internal templates, e.g. in creating HTML output:

    <title>{{title}}</title>

Although I'd only expect a writer to use this for maintaining consistency for marginal details that you don't want to stop and think about while writing, e.g. the name of the company the antagonist works for:

    title: The Floor is Lava
    credit: written by
    author: Pennywise Plath
    evilcorp: Joogle
   
    INT. {{ EVILCORP }} OFFICE - DAY

However, fountain probably works better if it's grandmother-proof (see https://groups.google.com/d/msg/fountain-dev/qD10HUl1LuE/NnCw8_fRBwAJ).

So with something like this, a writer can achieve the same result by just writing something like $evilcorp then doing a find & replace later. (This is what I would do.)

I like your suggestion of using title page syntax to define metadata and {{double-curlys}} to expand them.  

 

> It could also be used to implement alternate dialogue and production revisions.

Interesting. Can you expand a little on this?

Continuing on with your metadata model and combining it with a C directives approach, if the language supported string-only metadata conditionals where metadata is expanded in a conditional expression and the metadata tag is defined, then the expression evaluates to be true and if not present, evaluates false as regardless of the value as shown below

{{if metadata}}included text{{endif}} or you may prefer to close with {{/if}}.

version1:

{{if version1}} check it out.{{endif}}  evaluates true and includes the enclosed text.

{{if version2}} check it in.{{endif}}  evaluates false and nothing is expanded.

alternatively

{{if version1}} check it out.{{else if version2}}check it in.{{endif}}  is equivalent.

The following is more powerful:

revision: green

The {{if revision==green}} quick brown fox {{else}} lazy dog {{endif}}

alternatively:

The {{if revision==green}} quick brown fox {{else if revision==red}} lazy dog {{endif}}

This same metadata conditional syntax could be used to implement alternate dialogues as well.

rating: pg13

Frankly Scarlett, I don't give a {{if rating==pg13}}darn{else}}damn{{endif}}.

These small additions that would grant more power to fountain.  

Most people would never use them and their text would still look like a screenplay.

But the folks that need that power would be able to use the standard language and rest assured that their text would be rendered properly by all editors that properly implement the standard.

John has also suggested using for marking revised regions (see https://groups.google.com/d/msg/fountain-dev/Xv54y9jGIA0/q2bieH7yEgAJ). I tend to think it's easier to embed a diff utility in the host application.

I understand John and Stu's convictions that fountain files should look like screenplays.  A noble goal.  I'm just curious if that goal is achieved by limiting expansion of the specification?  It seems to me that the lack of spec growth simply forces others to create rogue extensions or worse yet limit the use of fountain itself?

 

> Good to see the forum with good active discussions. :)

It's mostly just me annoying John and Stu.

Happy to help out from time-to-time. :)

 

--
https://www.paulwrankin.com

[Paul W. Rankin]

Hi Blake,

Sorry for the delayed response.

On Tue, 17 Apr 2018, at 1:06 PM, Blake Henry wrote:
> >
> > However, now that I'm poking around I can't find where I got that
> > impression...
> >
>
> I found it. It's in the 'Title Page' section of the Fountain.io spec
> page: https://fountain.io/syntax#section-titlepage

Ah cool, thanks, I was worried I'd just made it up.

> I like your suggestion of using title page syntax to define metadata
> and {{double-curlys}} to expand them.

Yeah I think this is safe enough for individual developers to play
around with, i.e. it's not going to break any scripts coming in from
other Fountain apps.

> Continuing on with your metadata model and combining it with a C
> directives approach, if the language supported string-only metadata
> conditionals where metadata is expanded in a conditional expression
> and the metadata tag is defined, then the expression evaluates to be
> true and if not present, evaluates false as regardless of the value as
> shown below
>
> {{if metadata}}included text{{endif}} or you may prefer to close with
> {{/if}}.
>
> version1: {{if version1}} check it out.{{endif}} evaluates true and
> includes the enclosed text. {{if version2}} check it in.{{endif}}
> evaluates false and nothing is expanded. alternatively {{if version1}}
> check it out.{{else if version2}}check it in.{{endif}} is equivalent.
>
> The following is more powerful: revision: green The {{if
> revision==green}} quick brown fox {{else}} lazy dog {{endif}}
> alternatively: The {{if revision==green}} quick brown fox {{else if
> revision==red}} lazy dog {{endif}}
>
> This same metadata conditional syntax could be used to implement
> alternate dialogues as well. rating: pg13 Frankly Scarlett, I don't
> give a {{if rating==pg13}}darn{else}}damn{{endif}}.
>
> These small additions that would grant more power to fountain. Most
> people would never use them and their text would still look like a
> screenplay. But the folks that need that power would be able to use
> the standard language and rest assured that their text would be
> rendered properly by all editors that properly implement the standard.

Are you developing a Fountain app with such a conditional templating
engine? If so, muchos kudos to you. My opinion (which honestly ought to
carry no weight here) is that this might be a bit too much for 99.9% of
writers. But please don't let my opinion dissuade you.

> > John has also suggested using for marking revised regions (see
> > https://groups.google.com/d/msg/fountain-dev/Xv54y9jGIA0/q2bieH7yEgAJ).
> > I tend to think it's easier to embed a diff utility in the host
> > application.
> >
>
> I understand John and Stu's convictions that fountain files should
> look like screenplays. A noble goal. I'm just curious if that goal
> is achieved by limiting expansion of the specification? It seems to
> me that the lack of spec growth simply forces others to create rogue
> extensions or worse yet limit the use of fountain itself?

I used to have a very conservative perspective on the Fountain spec,
believing that it needed to be strictly standardised because if it
wasn't then... well I'm not sure what I thought would happen. But then I
heard John Gruber talking about his ambivalence towards any sort of
standardised Markdown.

I think he has the right idea: like Markdown, the basics in Fountain are
pretty solid; now developers can experiment and see what works. Call
these rogue extension, or maybe it's evolution. If you're making
something, I think John and Stu would probably encourage you to go ahead
and make it rather than wait for their permission. If the idea gains
traction then it will have a life of its own.

[Blake Henry]

Thanks Paul,

I’m not developing an app - there are way too many good ones out there already. I would just like to see Fountain apps gain the production-grade features that other apps have already.

Great advice on doing it and not waiting for permission. Maybe I can contribute by extending the libraries that are on the site to implement my suggestions? Honestly I should probably spend my time writing my stories rather than working on the tools, but I’m smitten with a technical mind.

Best regards,
Blake