Suggestion for alternate Beat data location

[rnkn]

Hello!

Thanks for your work on the Beat project and contribution to the Fountain community, it is much appreciated.

I'm the maintainer of a Fountain program for Emacs called Fountain Mode. In the anti-capitalist spirit, I like to keep writing in Fountain as program-agnostic as possible. With that in mind I have a suggestion for the EOF BEAT JSON data.

I understand that due to the plethora of features Beat implements on top of the Fountain spec there is clearly a need for somewhere to store the JSON data. The only problem is that when switching program this data is not aesthetically pleasant, or worse, may get deleted.

My humble suggestion is that the JSON data could be optionally stored external to the Fountain file. I have a couple of suggestions of how this might be achieved.

The first and most obvious is to store a .beat-data.json in the same directory alongside the source file. Beat need not expose an option to the user for this, rather advanced users could simply:

touch .beat-data.json

and if Beat detects such a file, data is stored there instead.

The obvious problem with this is that unless the user stores projects in their own directories (perhaps under version control) then there is a filename collision where multiple Fountain files exist in the same directory.

A little less elegant then is .beat-data-MY-SCRIPT.json where MY-SCRIPT is the source file filename sans file extension.

This then presents the problem data disconnection if the source file is renamed.

This could be solved where the name of the Beat data file is stored in a boneyard comment, e.g.

/* BEAT DATA FILE: .beat-data-43f776f1.json */

Or, even more outlandishly, an extension I'd like to see to the Fountain spec, a metadata extension, e.g.:

Title: My Script
X-Beat-Data-File: .beat-data-43f776f1.jso

The advantage of a metadata extension route is that it allows for other possible cross-program extensions to the Fountain spec, e.g. if the script has pages locked:

Title: My Script
X-Locked: yes

The disadvantage is that some Fountain programs put every metadata item on the title page. These programs would need to be taught to ignore X-* metadata.

Let me know if you're interested in this idea, and/or you'd prefer this conversation to happen over email :)

[lmparppei]

Hello! Nice to meet another Fountain developer!

I've struggled with this quite a bit, and always ended up at the current approach.

Using another file to store the data would be pretty nice and I played around the idea earlier, but there are a lot of usability pitfalls. Unlike people who dare to use Emacs, the majority of Beat users are very much non-tech-savvy, to the point that I often need to instruct how to save or rename files.

I'm not that worried about the data block getting removed, because it doesn't affect the actual content, it's just character bios, revisions etc., so I'm hoping that if someone is removing it, they know what they are doing. Sort of. Having another file which you'd need to move alongside the main one would have more risks about them getting out of sync and showing completely wrong stuff.

I originally thought about using TextBundle, which admittedly would be the most sensible approach, but the problem is that while you can dig the pure Fountain file from the bundle without any special tools, most users wouldn't know how to do that. Highland 2 uses TextBundle (maybe Slugline and Logline too?) but it sort of defeats the purpose of a portable format.

Also, as Beat is now distributed through Apple's App Store, it has to be sandboxed, which adds to the complexity. You need to request access on per-file-basis, requiring user interaction to explicitly show which file you want to touch. On top of that, iOS is even more strict about file security, so editing a single screenplay over iCloud on different platforms wouldn't be that easy anymore.

And yes – the data block is very ugly. Mostly because I implemented the thing during my early days as a scrappy beginner. Some values are single floats called Window width and Window height etc. instead of something simple like frame: [x,y,w,h]. Beat also stores a ton of empty arrays there for no reason. I should fix that. It wouldn't make it any more appealing, but at least a little less cluttered. :-)

When I originally put it there, I did try to engage in conversation with some other Fountain app developers about creating a standard setting block, but the idea didn't take off. I've tried to keep Beat as cross-app-compatible as possible, with the only exception being !!Mini slugs which is a pure Beat feature.

But still, metadata fields would be a wonderful and much needed addition to Fountain! The downside there is the same: other apps would display the additional fields as title page elements, unless they'd opt in to the idea.

For some reason or another, Beat was removed from the official Fountain site last year, but I've reached out to them to get it back, and also offered to help with modernizing the dated Fountain repository. Maybe if I can get a conversation open, we could start discussing some minor additions to the Fountain spec, instead of implementing different flavours from app to app.

[rnkn]

Of course! I did not consider moving the source file, which is a likely occurrence. And trying to get a non-tech-savvy person to understand moving a hidden file would surely be a nightmare. Best to work within the constraints of the technical abilities of your audience.

For some reason or another, Beat was removed from the official Fountain site last year, but I've reached out to them to get it back, and also offered to help with modernizing the dated Fountain repository. Maybe if I can get a conversation open, we could start discussing some minor additions to the Fountain spec, instead of implementing different flavours from app to app.

That's unfortunate. Surely this was by mistake. I can't imagine Stu/John removing an app on purpose. And Beat is a highly polished example of what can be achieved with Fountain.

I agree that using a TextBundle or package file is undesirable. I can understand why John went that route after running up against limitations with the plain text format.

But still, metadata fields would be a wonderful and much needed addition to Fountain! The downside there is the same: other apps would display the additional fields as title page elements, unless they'd opt in to the idea.

I think this is doable. The Fountain-dev community is small, so it would only take a few people willing to implement ignoring X-* text from the title page. I also like this format because it is there is precedence with email header extensions in RFC822.

Highland 2 seems to only export a select few metadata keys, so that's one down already. They have forged ahead with a lot of {{ key: value }} extensions, so I doubt they would reimplement these with X-Key: value even if Highland is de facto compatible now.

There is https://groups.google.com/g/fountain-dev which I set up some time ago. We had some fruitful discussion there when it started but it hasn't seen much activity in the last few years. But most Fountain developers should still be subscribed.

I'll reach out to the few developers I know and see about their position on X-* then consider posting to the Google Group.

Given this issue is mostly about the Beat data block, and that is resolved, I'll close in favour of a new issue for X-*.