Extending page break syntax

[Paul Rankin]

Currently page breaks can be forced with a line containing three or more consecutive equals signs:

===
or
=======
etc.

I'd like to suggest that additional info could be appended to this, for example, in two ways...

Forcing page numbers, with a line containing the page break syntax plus a alphanumeric string:

=== 12
or
==== 76A ====
etc.

And forcing the end of the script, with a line containing the page break syntax plus "end":

=== end
or
=== end ===
or
===== END ===
etc.

This provides a space to store junk outside the document, perhaps if an app wanted to use, oh gee I dunno, a text drawer or bin of some sort.....

--
Paul W. Rankin
www.paulwrankin.com

[Paul W. Rankin]

On Mon, 20 Jun 2016, at 07:08 PM, Hendrik Noeller wrote:

In which direction would you suggest the Page Numbering should point? Numbering the next page would feel intuitive to me, but that would prevent the user from numbering the first page without adding a blank page. Still, I generally approve of this idea, forcing numbering sounds like a good idea.

Yes numbering the following page. It matches any kind of numbering of headings or sections from any other text markup format I can think of.

I think numbering the first page is a non-issue as it's programmatically trivial to check whether there is any content before the page break mark.

About that text drawer or bin on the other hand, its certainly a nice thing for an App to have that space, but there is a problem:

It would break backwards- and cross compatibility because there are too many ways to use it:

- The user puts an === END to store stuff by hand or end a script prematurely

- An app implements a trashcan and puts fragments of deleted text there

- An app stores other information there

- An App doesn't care or hasn't been updated and just exports the junk onto the pdf

I think all of these things are fine. The only directive would be "don't print stuff below the line." What a user or developer wants to store there remains completely open.

As far as an app not being updated, this is always going to be an issue with growing a syntax, e.g. when John and Stu released Fountain 1.1 with forced-element syntax, those apps that did not recognise forced-element syntax would print these syntax marks instead of hiding them.

The three first approaches might work together if we agreed on a way of how to separate elements in this trash space, but it most certainly breaks backwards compatibility. Also, a user using the tag manually would wonder where his discarded things go when he starts to use an app that implements a bin, or another user might wonder where all the trash at the end of the document comes from when he stops using such an app.

I think maybe you're brainstorming an interesting variety of implementations, whereas I want to keep it simple...

=== end

...means end the export. Suggesting any extra manipulation of the text that gets placed below there would be an additional addition to the syntax.

I think fountain should not offer these kinds of surprises when swichting apps or just using a plain text editor, but stay clear and easy to use without knowing about these kinds of details.

I'm always interested if there's a disconnect in what appears obvious to me and what really is obvious. Do you think the average user would see...

=== end ===

...and misunderstand its meaning?

[Hendrik Noeller]

I very much agree with your point about page numbering, that would be a great addition to the syntax.

I see a risk with the "=== END" tag on the other hand, as it creates a space that could include lots of outdated or omitted content, or just plain garbage.

If a user owns a document that uses the end tag, especially created by an editor for a e.g. bin without the users knowledge, and then exports or prints it from a different app that does not understand the "=== END", he could by accident publish or share a lot of old content he doesn’t want anyone to see.

This appears way more severe to me than other anomalies that can arise from a syntax update, like missing formatting if an app doesn’t understand a „~“ as Force Lyrics. I don’t think breaking backwards compatibility like that is a good idea.

-- 
You received this message because you are subscribed to the Google Groups "Fountain Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fountain-dev...@googlegroups.com.
To post to this group, send email to founta...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fountain-dev/1466333177.2301916.641983049.416FEAAD%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/d/optout.

[Paul Rankin]

On Tue, 21 Jun 2016, at 08:33 PM, Hendrik Noeller wrote:

I very much agree with your point about page numbering, that would be a great addition to the syntax.

 

Cool.

 

I see a risk with the "=== END" tag on the other hand, as it creates a space that could include lots of outdated or omitted content, or just plain garbage.

If a user owns a document that uses the end tag, especially created by an editor for a e.g. bin without the users knowledge, and then exports or prints it from a different app that does not understand the "=== END", he could by accident publish or share a lot of old content he doesn’t want anyone to see.

This appears way more severe to me than other anomalies that can arise from a syntax update, like missing formatting if an app doesn’t understand a „~“ as Force Lyrics. I don’t think breaking backwards compatibility like that is a good idea.

 

Remember I'm only suggesting that the section exist (and doesn't export), not that it hides text from the user or anything untoward like that. You might be overestimating the scope of the suggestion.....

 

(Also, technically breaking backwards compatibility means changing something that prevents prior scripts from working properly, which doesn't apply for this new hypothetical script. Breaking changes would be like saying "@" should now mean transition.)

 

[John August]

Forcing page numbers (or "baking them in") with a syntax like ===17 feels exactly right. It's Fountain-y. 

It doesn't say anything about how the page number should be displayed, just that this is, by decree, page 17.

What can go in this spot? Are all of these valid?

===17

===84A

===45A-J

===POST-CREDITS

I'd recommend that all of them be allowed, yet on a practical level is does make sequential numbering more challenging. Obviously the page after 17 should be 18. 

But should the page after 84A be 84B or 85? My hunch is that unless it specifically is marked 84B, apps should assume 85. 

Perhaps as a general rule, apps should attempt sequential numbering after being handed a "clean" number. Otherwise, they should back up and work off of the last clean number they had.

First example (automatic numbering unless marked otherwise).

...

17

18

===18A

===18B

19 (app looks back 18)

20

...

Second example:

...

45

===45A

===45B-F

=== (no number given, so automatically 46)

===46A

47 (app looks to 46, which was forced for some reason, but is clean)

Third example:

...

20

21

===SPECIAL READER NOTE

22  (app looks back 21)

...

Does this make sense for everyone?

[Hendrik Noeller]

Yes, this is perfect!

--
You received this message because you are subscribed to the Google Groups "Fountain Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fountain-dev...@googlegroups.com.
To post to this group, send email to founta...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/fountain-dev/81ba632f-9426-4243-baf3-24cf3c8282a3%40googlegroups.com.

[John August]

The ===END syntax strikes me as problematic.

Does every Fountain file need one? Presumably not.

So some files would have them and some wouldn't. But since it's visible to the user, it might seem like it's required.

What happens when the user deletes it? How can you make it a good experience for both the power user and the newbie?

On a practical level, what we've been doing in Highland 2 is keeping our extra stuff in a well-labeled omit section /* */ at the end of the document. It travels as part of the file, but we don't show it to users. When you open these files in other apps, I think it's clear to users what this stuff is. We try to keep everything well-labeled.

BTW, I'm happy to have a discussion about whether this information should be in double-braces {{ }} rather than omit.

[Stu Maschwitz]

John, I like your page numbering proposal and agree that the ===END syntax is problematic. It feels right to me that any app-specific scrap/notes/etc. area should be stored in brackets at the end of the file.

-Stu

[Paul Rankin]

On Thu, 23 Jun 2016, at 01:20 AM, John August wrote:

Forcing page numbers (or "baking them in") with a syntax like ===17 feels exactly right. It's Fountain-y. 

 

It doesn't say anything about how the page number should be displayed, just that this is, by decree, page 17.

 

What can go in this spot? Are all of these valid?

 

===17

===84A

===45A-J

===POST-CREDITS

 

I'm all for allowing the writer complete freedom, so yeah, whatever goes.

 

One question about

 

===45A-J

 

My thought is this would display "45A-J" on the corner of a single page, not denote a range. If the intention was to denote a range I think that can get confusing.

 

I'd recommend that all of them be allowed, yet on a practical level is does make sequential numbering more challenging. Obviously the page after 17 should be 18. 

 

But should the page after 84A be 84B or 85? My hunch is that unless it specifically is marked 84B, apps should assume 85. 

 

I agree that sequential numbering should be the default, i.e. assume 85 in this case.

 

Perhaps as a general rule, apps should attempt sequential numbering after being handed a "clean" number. Otherwise, they should back up and work off of the last clean number they had.

 

Is there a need to differentiate clean numbers?

 

=== 55

=== 55A

=== 55JAPAN

 

My thinking is the page after all of these is 56. Or have I misunderstood?

 

First example (automatic numbering unless marked otherwise).

 

[...]

 

Does this make sense for everyone?

 

These examples are exactly what I had in mind. They're all compatible, no?

 

The end goal I have in mind is page locking. I'll try to illustrate a rudimentary example and see if we can poke holes in it. Say we go into production with a Fountain script that has already been exported to PDF, printed and distributed. Page 26 needs a rewrite that will likely spill onto B-pages.

 

The page 27 of our paper/PDF copy begins with...

 

Miranda places the key on the table.

 

...so we look at our Fountain file and add...

 

=== 27

 

Miranda places the key on the table.

 

Now we do the rewrite, which adds two extra pages of content, so in an unlocked script, page 27 would now be 29.

 

At this point the writer should not need to worry about anything else. During export, the app paginates 26, 27, 28, 29 where it hits the === 27 mark on 29. The app goes back to 26 and numbers

26 = 26

27 → 26A

28 → 26B

29 → 27

28 = 28

 

And then from the PDF we print out 26, 26A, 26B on our new colour paper.

 

I recognise that page-locking in theory vs page-locking in practice is going to be very different, but this seems like it could work.

[Paul Rankin]

On Thu, 23 Jun 2016, at 01:35 AM, John August wrote:

The ===END syntax strikes me as problematic.

 

Does every Fountain file need one? Presumably not.

 

Nope, purely optional.

 

At the moment, if we abstract an exporter's top-level process into basic language it's something like...

 

1. read the title page metadata up to here

2. export the content from here to end-of-file

 

My idea is...

 

1. read the title page metadata up to here

2. export the content from here to end-of-file or "=== end"

 

So some files would have them and some wouldn't. But since it's visible to the user, it might seem like it's required.

 

I think this is just the same as various title page metadata. Is a "title: STRING" field required? No but most Fountain files have it.

 

What happens when the user deletes it? How can you make it a good experience for both the power user and the newbie?

 

In my head it's just like a "--- CUT HERE ---" label on a bag of food. I think most users would get that if it's not there then nothing gets cut, no?

 

On a practical level, what we've been doing in Highland 2 is keeping our extra stuff in a well-labeled omit section /* */ at the end of the document. It travels as part of the file, but we don't show it to users. When you open these files in other apps, I think it's clear to users what this stuff is. We try to keep everything well-labeled.

 

Highland 2 beta is what inspired my thinking, just didn't want to divulge a possible beta secret publicly.

 

As a user, I was a little confused as to where the bin/scratchpad stuff was stored. Initially I thought maybe in the Application Support folder. Then opened in Emacs and saw the hidden text and figured there could be a Fountain default way to do it.

 

In most OS text UIs the easiest point to get to is the top, the next is the bottom. (In OS X it's cmd-↑ and cmd-↓, in Emacs it's M-< and M-> and in Windows I assume it's ctrl-alt-del something something.) So if there is some kind of Fountain place for scratchpad, bin, etc. I figure the end of the file would be it.

 

In many apps, comment (omit) syntax will override regular syntax highlighting. I'd like to be able to store whole scenes in an out-of-the-way spot while keeping the syntax highlighting.

 

In Emacs a user can have multiple windows open looking at different places in a single file. So you can have one window looking at the scene you're working on, and another side window looking at the bin section past the "=== end."

 

I think "=== end" is intuitive enough, as says to users "this is a page break that ends the script."

 

BTW, I'm happy to have a discussion about whether this information should be in double-braces {{ }} rather than omit.

 

I think your current implementation is the best. Given that the text is hidden in Highland 2, if a user exports from another app that hasn't yet implemented curly brace stuff they will get this exported without ever seeing it before....

 

{{ [Highland-ScratchPad-Start]

This is my scratchy text.

[Highland-ScratchPad-End] }}

 

[Paul W. Rankin]

After implementing the below quoted proposal in fountain-mode for emacs, I found that the end-of-script syntax became problematic for outline structure:
=== end ===

So I'd like to separate that out from the original proposal for page break numbering, but still encourage the addition of the page break numbering syntax:
=== 76 ===

I actually have a glimmer of hope that the introduction of page break numbering syntax like this allows for page locking in a fountain script. The theory is that if the fountain editing program can accurately count pages, then a "Lock Pages" command could linearly parse the script, inserting these numbered page breaks (breaking elements as necessary).

A fountain editing program could maybe then offer a user preference to "protect" page breaks, i.e. make this text non-editable.

Any discussion on the conceptual feasibility of this avenue of page locking would be appreciated :)

PWR

--
https://www.paulwrankin.com